From: 
Sent: 
To: 

Subject: 


abbott 

Monday, January 02, 1995 7:12 PM 
'khp' 

coding suggestion 


I was just starting to look at cosines as part of my terp dsplib studies. Looked at your 
latest vco code and thought the integrator could be done better. I haven't tested this, 
but it should work: 
Replace 

tx = gcopy32 (x) ; 

/* initialize sliding integration */ 
tzO = gcopy32 (z [0] ) ; 
tzl = gcopy32 (z [0] ) ; 
/* integrate mod 2 A 32 */ 


tx32 

= gshll28(tx, 

32) ; 

tx64 • 

= gshll28 (tx, 

64) ; 

tx96 

= gshl!28 (tx, 

96) ; 

tzO = 

gadd32 (tzO, 

tx) ; 

tzl = 

gadd32 (tzl, 

tx) ; 

tzO = 

gadd32 (tzO, 

tx3 2) ; 

tzl = 

gadd32 (tzl, 

tx) ; 

tzO = 

gadd32 (tzO, 

tx64 ) ; 

tzl = 

gadd32 (tzl, 

tx) ; 

tzO = 

gadd32 (tzO, 

tx96) ; 

tzl = 

gadd32 (tzl, 

tx) ; 

tzl = 

gadd32 (tzl, 

tx) / 

tzl = 

gadd32 (tzl, 

tx32) ; 

tzl = 

gadd32 (tzl, 

tx64 ) ; 

tzl = 

gadd32 (tzl, 

tx96) ; 


with 

tx = gcopy32 (x) ; 

/* initialize sliding integration */ 
tz = gcopy32 ( z [0] ) ; 
/* integrate mod 2 A 32 */ 
tx2 = gshl32 (tz, 1) ; 
tx4 = gshl3 2 (tz, 2) ; 
txll = gexpand32 (tx, 32); 
tx21 = gshll2 8(tx2, 64); 
tx = gadd32(tx, txll); 
tx = gadd32(tx, tx21) ; 
tzO = gadd32(tz, tx) ; 
tzl = gadd32(tz0, tx4); 
Here's the mathematica (also unchecked) 


tx 


g [32] [x, x, x, x] 




tz 


g [32] [z, z, z, z] 




tx2 


g [32] [2x, 2x, 2x, 

2x] ; 

/* 

shift */ 

tX4 


g [32] [4x, 4x, 4x, 

4x] ; 

/* 

shift */ 

txll 


g [32] [ x, 0, x, 

03 ; 

/* 

expand */ 

tx21 


g[32] [2x, 2x, 0, 

03 ; 

/* 

shift */ 

tx 


g[32] [2x, x, 2x, 

x] ; 

/* 

txll+tx */ 

tx 


g[32] [4x, 3x, 2x, 

xj ; 

/* 

tx21+tx */ 

tzO 


g [32] [z+4x, z+3x, 

z+2x, 

z+x] 

/* tz+tx */ 

tzl 


g [32] [z+8x, z+7x, 

z+6x, 

z+5x] 

/* tz0+tx4 


Looks like 10 instructions vs 18. That should help a little! 


- Curtis 
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From: geert (Geert Rosseel) 

Sent: Tuesday, January 03, 1995 10:42 AM 

To: 'wampler 1 

Cc: 'tbf 

Subject: New Euterpe 

Hi Kurt, 

There is a new placement for Euterpe in 
/n/ghidra/s3/geert/euterpe/verilog/bsrc/gards2 
Thsi contains the full Euterpe (excluding Cerberus ) 
Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Tuesday, January 03, 1995 11:08 AM 

'geert' 

'tbr' 

Re: New Euterpe 


Geert writes: 

> There is a new placement for Euterpe in 
> 

> /n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards2 
> 

> Thsi contains the full Euterpe (excluding Cerberus ) 

OK - I've got a copy of the source files; I'll route it and see if things 
have improved. I should have a line search result early this afternoon. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


tbr 

Tuesday, January 03, 1995 1:26 PM 
'geert' 

euterpe power 


Follow Up Flag: Follow up 
Flag Status: Red 


Where are you building the top level? I'd like to get the latest SOFA 
power estimate to hand to the mechanical folks. I assume all I need 
is the total count of isrc's from the SOFA x 30uA each at knob setting 
6 to get total current. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Tuesday, January 03, 1995 1:26 PM 

To: 'geert' 

Subject: euterpe power 


Where are you building the top level? I'd like to get the latest SOFA power estimate to 
hand to the mechanical folks. I assume all I need is the total count of isrc's from the 
SOFA x 3 0uA each at knob setting 
6 to get total current . 

Tim 
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From: 
Sent: 
To: 

Subject: 


graham (Graham Y. Mostyn) 
Tuesday, January 03, 1995 5:10 PM 
'graham'; 'hessam'; 'abbott' 
Re: ISDN 


The reason that I raised this issue is that Hessam' s mail deemed certain ISDN solutions to 
be unworkable, but these reasons were specific to Pandora: 

eg "Mitel ST bus interface to Calliope and uP bus to Euterpe not feasible since the 
decision has been made to design the box in a modular fashion. . . 
data/address bus needed to run across the modules..." 

This argument is not applicable to Hestia. 

Now, we did initially talk about modifying the Hestia board to add the 3xISDN capability, 
but recent thinking has focussed on wireline modules for Pandora. 

I think there is a need for both, but I just want to be sure that although Pandora has its 
own mechanical/ interconnect constraints, we don't overlook a perhaps easier modification 
of Hestia. 

Hessam, surely Hestia with ISDN can do more than a Combinet function! ! 
Graham . 

> From abbott@tallis Tue Jan 3 14:56:46 1995 

> Date: Tue, 3 Jan 95 14:56:44 -08 00 

> From: abbot t@tal lis (Curtis Abbott) 

> To: graham@tallis (Graham Y. Mostyn), hessamOtallis 

> Subject: ISDN 

> Content -Length: 1168 

> 

> Graham Y. Mostyn wrote (on Tue Jan 3) : 

> 

> The recent mail on ISDN has addressed adding a wireline capability 

> (ISDN, Tl etc.) to the modular Pandora. 
> 

> I'm not sure I agree. The mail that Hessam sent, and that I amplified 

> on, addressed changes to Calliope that would allow up to 3 (or perhaps 

> more) S interfaces to be connected to a modified Hestia, probably in 

> the form of Mitel 8931 's, or perhaps the Siemens or National 

> equivalents. I'm most anxious to get Alan's thoughts on the proposal 

> when he gets back. 
> 

> I assume ISDN on modular Pandora is just a matter of plugging a board 

> and adding software. Tony has an action to get info on PCI ISDN 

> cards, of which there were none 9 months ago, but David B claims there 

> are now. 
> 

> As to adding Ethernet, I still like the idea very much. This is a 

> fairly high bandwidth pipe that's widely used; if it could be cheap, 

> it clearly opens opportunities for us. 
> 

> As to markets... the point of integrating ISDN relatively cheaply is 

> to have a telco pipe to which to apply our computing power. Probably 

> for videophone. I don't think anyone's thinking of building "just" a 

> Combinet clone with Hestia or Pandora. 
> 

> - Curtis 


> 


> 
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From: fwo (Fred Obermeier) 

Sent: Tuesday, January 03, 1995 8:29 PM 

To: 'hardheads' 

Cc: 'fwo' 

Subject: Celltest installation. 

Celltest users, 

I'm doing a big releasebom of celltest and csyn. We'll be using the new set 
of csyn rules and csyn signal name mapping. Almost all of the representative 
leaf cells have passed csyn and celltest with these csyn rules and celltest 
voltages. Most of the full set of leaf cells have passed rcdl , rcd5, and rcd6 
as well. I'm still running on rcd7. I have run tbr_euterpe-passl .spivs 
through these new rules too and the problems have been previously sent. 
I'm still trying to get another tbr_euterpe-passl .spivs built cleanly so 
that new csyn results can be distributed again. 

Of course with these large number of changes to csyn and celltest, 
there's bound to be something that no longer works, so let me know 
when you find something. 

Fred. 
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To: 


Subject: 


Sent: 


From: 


Cc: 


tbr 

Wednesday, January 04, 1995 12:03 AM 

'torn' 

'geert' 

proteus/snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

I was updating it this evening and made the stupod error of getting 
the BOM as me rather than chip, I then did a 

find -user tbr -exec rm -r {} \; 

to clean it up followed by another getbom. 

Somehow, the ownership of the compass/layouts directory had become tbr 
so it removed the lot (apparantly) and the new getbom has been 
grinding on for hours pulling them out again, 

I'm a bit worried in case anything nasty might have happened. In 
particular, I got the following warnings in amongst it all: 

/n/auspex/s23/euterpe-proteus-cp: File "Makefile. defs" needs to be evicted (same name as a file that is being extracted) - 
moving to .#Makefile.defs.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6.1y" needs to be evicted (same name as a file that is being 
extracted) - moving to .#adl6.1y.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6stl.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#ad 1 6st 1 .ly .No - (status 1 6) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6st2.1y" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#adl6st2.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "cli.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#cli.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "ledsegdrv.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#ledsegdrv.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "locked-cells" needs to be evicted (same name as a file that is being 
extracted) - moving to .#locked-cells.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/com pass/layouts: File "mosne_25xp45.1y" needs to be evicted (same name as a file that is 
being extracted) - moving to ,#mosne__25xp45.1y.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mosne_25xp95_f.iy" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mosne_25xp95 f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mosne_25xp95_p45drn.ly" needs to be evicted (same name as a file 
that is being extracted) - moving to ,#mosne_25xp95„p45drn.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mosne_2xp95_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mosne_2xp95_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts; File "mospe_25x2p0_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to ,#mospe_25x2pO_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mospe_25xp45.1y" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mospe_25xp45.1y.No - (status 1 6) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mospe_25xp5_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mospe_25xp5_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mospe_25xp95_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mospe_25xp95_f.ly.No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts: Fi le 
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"mospe_25xp95_p45drn.ly" needs to be evicted (same name as a file that is being extracted) - moving 
to .#mospe_25xp95_p45dm.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mospe_2xp95_f,ry" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mospe_2xp95_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "mospp_25x2p0_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#mospp_25x2pO_f.ly.No - (status 16) 

/n7auspex/s23/euteipe-proteus-cp/compass/layouts: File "nf_25x2p0_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#nf_25x2pO_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "n _25xp5_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#n f_25xp5_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "nfc_25xlp5_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#nfc_25xlp5_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "nfc_25x2p0_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#nfc_25x2pO_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "npolyscf.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#npolysc_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "nsas_f.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#nsas_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "nsdecendcap_2udr.ly" needs to be evicted (same name as a file that 
is being extracted) - moving to .#nsdecendcap_2udr.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "nsp_f.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#nsp_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_bjtla.ly" needs to be evicted (same name as a file 
that is being extracted) - moving to .#p61 l_etest_lxlO_bjtla.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_bjtlb.ly" needs to be evicted (same name as a file 
that is being extracted) - moving to ,#p61 letest _lxlO_bjtlb.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_cstringla.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to ,#p61 l_etest_Ixl(_cstringIa.Iy.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_cstringlb.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to ,#p61 l_etest_lxlO_cstringlb.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_nmoslb.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to ,#p61 l_etest_lxlO_nmoslb.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 1_etest_lxl0_nmos2b.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to Jp61 l etest IxlO_nmos2b.Iy,No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p6I I_etest_lxl0_nmos3b.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to .#p61 l_etest_lxlO_nmos3b.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 I_etest_lxl0_pmos2a.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to .#p61 l_etest_lxlO_pmos2a.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 1_etest_lxl0_pmos2b.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to .#p61 l_etest_lxlO_pmos2b.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p61 l_etest_lxlO_pmosma.ly" needs to be evicted (same name as a 
file that is being extracted) - moving to .#p61 l_etest_lxlO_pmosma.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/Iayouts: File "pad_lxlOa.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#pad_lxlOa.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "pad_lxlOb.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#paoMxlOb.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "pf_25x2p0_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to ,#pf_25x2pO_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "pf_25xp5_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#pf_25xp5_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/Iayouts: File "ppolyscf.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#ppo!ysc_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/Iayouts: File "proteus.db" needs to be evicted (same name as a file that is being 
extracted) - moving to .#proteus.db.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "psp_f.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#psp_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "rotated_nmosl_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to ,#rotated _nmosl_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "rotated_nmos2 f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#rotated_nmos2_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "rotated_pmosl_f.ly" needs to be evicted (same name as a file that is 
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being extracted) - moving to .#rotated_pmosl_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "rotated_pmos2_f.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#rotated_pmos2_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "subscontfilsca.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#subscontf11sca.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "subscontfilscb.ly" needs to be evicted (same name as a file that is 
being extracted) - moving to .#subscontfilscb.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "vlsi.cko" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#vlsi.cko.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "vlsi.log" needs to be evicted (same name as a file that is being 
extracted) - moving to ,#vlsi.log.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "iobyteOm.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to JiobyteOm.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "iobytem.Iy" needs to be evicted (same name as a file that is being 
extracted) - moving to Jiobytem.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "iocdr2pm.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#iocdr2pm.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "iockdrvm.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#iockdrvm.ly.No - (status 16) 

and I have no idea why these would have been singled out. Can you 
take a look at what's there please to see if there is any obvious 
problem? (Most of the files seem to have execute permission turned 
on, but I see that is also true in /u/chip). 

Thanks 
Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, January 04, 1995 12:03 AM 

To: 'torn' 

Cc: 'geert' 

Subject: proteus/snapshot 


I was updating it this evening and made the stupod error of getting the BOM as me rather 
than chip . I then did a 

find -user tbr -exec rm -r {} \; 

to clean it up followed by another getbom. 

Somehow, the ownership of the compass /layouts directory had become tbr so it removed the 
lot (apparantly) and the new getbom has been grinding on for hours pulling them out again. 


I'm a bit worried in case anything nasty might have happened, 
following warnings in amongst it all: 


In particular, I got the 


/n/auspex/ s2 3 /euterpe -proteus - cp : File "Makef ile . def s" needs to be evicted (same name as a 
file that is being extracted) - moving to . #Makef ile . def s .No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "adl6.1y" needs to be evicted (same 
name as a file that is being extracted) - moving to .#adl6. ly.No - (status 16) 

/n/auspex/s2 3/euterpe-proteus-cp/compass/layouts : File "adl6stl . ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #adl6stl . ly .No - (status 16) 

/n/auspex/ s23 / euterpe-proteus -cp / compass/layouts : File "adl6st2 . ly rf needs to be evicted 

(same name as a file that is being extracted) - moving to . #adl6st2 . ly .No - (status 16) 

/n/ auspex/s2 3 /euterpe-proteus -cp/compass/ layout s : File "cli.ly" needs to be evicted (same 
name as a file that is being extracted) - moving to .#cli, ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus -cp/compass /layouts: File "ledsegdrv. ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . 
#ledsegdrv. ly .No - (status 16) 

/n/auspex/ s2 3 /euterpe-proteus -cp/compass/ layouts : File "locked-cells" 

needs to be evicted (same name as a file that is being extracted) - moving to . ilocked- 
cells.No - (status 16) 

/n/auspex/s23 /euterpe-proteus -cp/compass/layouts : File "mosne_25xp45 . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mosne_ 

25xp45,ly.No - (status 16) 

/n/auspex/s23 /euterpe-proteus- cp/compass/layouts : File "mosne_25xp95_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to .#mosne_ 

25xp95_f .ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File M mosne_25xp95_p45drn . ly" needs to 
be evicted (same name as a file that is being extracted) - moving to . #mosne_25xp95 
_j)4 5drn . ly . No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "mosne_2xp95_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mosne_ 

2xp95_f . ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "mospe_25x2p0_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mospe_ 

25x2p0_f .ly.No - (status 16) 

/n/auspex/ s2 3 /euterpe-proteus-cp/compass/ layouts : File "mospe_25xp4 5 .ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mospe_ 

25xp45. ly.No - (status 16) 

/n/auspex/ s2 3 /euterpe-proteus-cp/compass/ layouts : File "mospe_25xp5_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mospe_ 

25xp5_f .ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus -cp/compass /layouts : File "mospe_25xp95_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to .#mospe_ 

25xp95_f .ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "mospe_25xp95_jp4 5drn. ly" needs to 
be evicted (same name as a file that is being extracted) - moving to . #mospe_2 5xp95 
_p45drn. ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus -cp/compass/ layouts : File "mospe_2xp95_f . ly" 
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needs to be evicted (same name as a file that is being extracted) - moving to . #mospe_ 
2xp95_f .ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus-cp/ compass /layouts : File "mospp_2 5x2p0_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #mospp_ 

25x2p0_f .ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus-cp/ compass /layouts : File "nf_25x2p0_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #nf_25x2p0 
_f. ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "nf_25xp5_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #nf_25xp5 
_f. ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts ; File "nf c_25xlp5_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #nfc_25xlp5 
_f. ly.No - (status 16) 

/n/auspex/s2 3 /euterpe -proteus - cp/compass/ layouts : File "nf c_25x2p0_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #nfc_25x2p0 

f. ly.No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "npolysc_f . ly" 
needs to be evicted (same name as a file that is being extracted) - moving to . 
#npolysc_f . ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "nsas_f.ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #nsas_f . ly.No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "nsdecendcap_2udr . ly" needs to be 
evicted (same name as a file that is being extracted) - moving to . #nsdecendcap_2udr . ly.No 
- (status 16) 

/n/auspex/ s2 3 /euterpe -proteus- cp/compass/ layouts : File "nsp_f .ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #nsp_f . ly.No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "p611_etest_lxl0_bj tla . ly" needs to 
be evicted (same name as a file that is being extracted) - moving to . #p6ll etest_lxlO 
_bjtla. ly.No - (status 
16) 

/n/auspex/s2 3 /euterpe -proteus -cp/compass /layouts: File "p611_etest_lxl0_bj tlb . ly " needs to 
be evicted (same name as a file that is being extracted) - moving to . #p611_etest_lxl0 
_bj tlb. ly.No - (status 
16) 

/n/auspex/s23/euterpe-proteus-cp/compass/ layouts : File "p611_etest_lxl0_cstringla . ly" 
needs to be evicted (same name as a file that is being extracted) - moving to .#p611 
_etest_lxlO_cstringla. ly.No - (status 16) 

/n/auspex/ s2 3 /euterpe -proteus- cp/compass/ layouts : File "p611_etest_lxl0_cstringlb . ly" 
needs to be evicted (same name as a file that is being extracted) - moving to .#p611 
_etest_lxlO_cstringlb . ly.No - (status 16) 

/n/ auspex/s2 3 /euterpe -proteus -cp/compass/ layout s : File "p611_etest_lxl0_nmoslb . ly " needs 
to be evicted (same name as a file that is being extracted) - moving to . #p611_etest_lxl0 
_nmoslb. ly.No - (status 
16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p611_etest_lxl0_nmos2b. ly" needs 
to be evicted (same name as a file that is being extracted) - moving to , #p611_etest_lxl0 

nmos2b . ly.No - (status 
16) 

/n/auspex/s23 /euterpe-proteus- cp/compass/ layouts : File "p611_etest_lxl0_nmos3b . ly " needs 
to be evicted (same name as a file that is being extracted) - moving to . #p611_etest_lxl0 
_nmos3b. ly.No - (status 
16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p611_etest_lxl0_pmos2a . ly" needs 
to be evicted (same name as a file that is being extracted) - moving to .#p611_etest_lxl0 
_j?mos2a. ly.No - (status 
16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "p611_etest_lxl0_pmos2b . ly" needs 
to be evicted (same name as a file that is being extracted) - moving to . #p611_etest_lx!0 
_jpmos2b. ly.No - (status 
16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "p611_etest_lxl0_pmosma . ly " needs 
to be evicted (same name as a file that is being extracted) - moving to . #p611_etest_lxl0 
_pmosma. ly.No - (status 
16) 

/n/auspex/s23 / euterpe -proteus- cp/compass /layouts : File "pad_lxlOa . ly " 

needs to be evicted (same name as a file that is being extracted) - moving to . #pad_ 

IxlOa. ly.No - (status 16) 
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/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "pad_lxlOb. ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #pad_ 

1x10b. ly.No - (status 16) 

/n/auspex/ s2 3 /euterpe-proteus-cp/ compass /layouts : File "pf_25x2p0_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #pf_25x2p0 
_f, ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File M pf_25xp5_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . #pf_25xp5 
_f.ly.No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "ppolysc_f . ly" 

needs to be evicted (same name as a file that is being extracted) - moving to . 

#ppolysc_f . ly .No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "proteus.db" needs to be evicted 
(same name as a file that is being extracted) - moving to . #proteus . db .No - (status 16) 

/n/auspex/s23/euterpe-proteus-cp/corapass/layouts : File "psp_f -ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #psp_f . ly .No - (status 16) 

/n/ auspex/s2 3 /euterpe-proteus-cp/ compass/ layouts : File "rotated_nmosl_f . ly" needs to be 

evicted (same name as a file that is being extracted) - moving to . #rotated_nmosl_f . ly . No 

- (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "rotated_nmos2_f . ly " needs to be 
evicted (same name as a file that is being extracted) - moving to . #rotated_nmos2_f . ly .No 

- (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "rotated_pmosl_f . ly" needs to be 
evicted (same name as a file that is being extracted) - moving to . #rotated_pmosl__f . ly .No 

- (status 16) 

/n/auspex/s23 /euterpe-proteus-cp/compass/ layouts : File "rotated_j?mos2_f . ly" needs to be 
evicted (same name as a file that is being extracted) - moving to . #rotated_pmos2_f . ly.No 

- (status 16) 

/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "subscontf ilsca. ly" 
needs to be evicted (same name as a file that is being extracted) - moving to . 
ttsubscontf ilsca . ly.No - (status 16) 

/n/auspex/s2 3 /euterpe-proteus-cp/ compass /layouts : File " subscontf ilscb. ly" 
needs to be evicted (same name as a file that is being extracted) - moving to . 
#subscontf ilscb. ly.No - (status 16) 

/n/auspex/ s2 3 /euterpe-proteus-cp/ compass/ layout s : File "vlsi.cko" needs to be evicted 
(same name as a file that is being extracted) - moving to . #vlsi . cko . No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "vlsi.log" needs to be evicted 
(same name as a file that is being extracted) - moving to . #vlsi . log .No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File " iobyteOm . ly " needs to be evicted 
(same name as a file that is being extracted) - moving to . ftiobyteOm . ly . No - (status 16) 
/n/auspex/ s2 3 /euterpe-proteus-cp/ compass/ layout s : File "iobytem.ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #iobytem . ly . No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File "iocdr2pm. ly" needs to be evicted 
(same name as a file that is being extracted) - moving to . #iocdr 2pm. ly.No - (status 16) 
/n/auspex/s23/euterpe-proteus-cp/compass/layouts : File " iockdrvm. ly" needs to be evicted 
(same name as a file that is being extracted) - moving to .# iockdrvm. ly .No - (status 16) 

and I have no idea why these would have been singled out . Can you take a look at what 1 s 
there please to see if there is any obvious problem? (Most of the files seem to have 
execute permission turned on, but I see that is also true in /u/chip) . 

Thanks 
Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, January 04, 1 995 5:10 AM 

To: 'geert@rhea' 

Subject: pager log message 

page from chip to geert : 

Release euterpe/verilog/bsrc/io BOM 33.0 initiated by brianl completed @ Wed Jan 4 
03:08:19 PST 1995 with exit status 0.. chip 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, January 04, 1 995 1 0:45 AM 

To: 'craig'; 'lisar' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Wed Jan 4 08:44:32 PST 1995 

Copy number: 283 

Copy registered to: David Bulfer 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore.macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore . ps 

Printed to: rsh plotter lpr -PCraig 

Recorded in file: /u/ craig/ document s /Regis trationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: torn (Tom Laidig) 

Sent: Wednesday, January 04, 1 995 1 1 :34 AM 

To: 'Tim B. Robinson' 

Cc: 'geert (Geert Rosseel)'; 'torn (Thomas Laidig)' 
Subject: Re: proteus/snapshot 

Tim B. Robinson writes: 


jl was updating it this evening and made the stupod error of getting 
jthe BOM as me rather than chip. I then did a 

I 

(find -user tbr -exec rm -r {} \; 
I 

|to clean it up followed by another getbom. 
I 

| Somehow, the ownership of the compass/layouts directory had become tbr 
jso it removed the lot (apparantly) and the new getbom has been 
jgrinding on for hours pulling them out again. 
I 

(I'm a bit worried in case anything nasty might have happened. In 
[particular, 1 got the following warnings in amongst it all: 

I 

|/n/auspex/s23/euterpe-proteus-cp: File "Makefile.defs" needs to be evicted (same name as a file that is being extracted) - 
moving to .#Makefile.defs.No - (status 16) 

|/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6.1y" needs to be evicted (same name as a file that is being 
extracted) - moving to .#adl6.1y.No - (status 16) 

|/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6st1 ,ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#adl6stl.ly.No - (status 16) 

|/n/auspex/s23/euterpe-proteus-cp/compass/layouts: File "adl6st2.1y" needs to be evicted (same name as a file that is being 
extracted) - moving to .#ad!6st2Jy.No - (status 16) 

|/n/auspex/s23/euterpe-proteus-cp/compass/Iayouts: File "cli.ly" needs to be evicted (same name as a file that is being 
extracted) - moving to .#cli.ly.No - (status 16) 

[etc.] 


jand I have no idea why these would have been singled out. Can you 
jtake a look at what's there please to see if there is any obvious 
jproblem? (Most of the files seem to have execute permission turned 
jon, but I see that is also true in /u/chip). 

For reasons unknnown to me (I suspect plain stupidity) compass normally 
turns on execute permission for layout files. The ones that don't have 
execute permission set were probably massaged by some text editor or 
derived some other way originally. 

I don't know why these files were singled out, but I suspect the problem 
in general occurred because when you removed all files owned by tbr you 
got rid of the BOM file, so these files appeared as if they existed 
without being in the BOM. Obviously this doesn't explain why the list 
is so short. Anyway, I compared all .# files with the corresponding 
normal files, and found no differences, except for latchxl .iy, which 
wasn't in your list... apparently, this kind of thing has happened in 
the past, and the .#latchxUy file is way out of date. I suggest 
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simply deleting these .# files, and forgetting the matter. I'll also 
fire up a find to see how many more such things we have. 


ooooO Ooooo 

( J L ) 
\( tau )/ 

(J o 
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To: 

Subject: 


Sent: 


From: 


tbr 

Wednesday, January 04, 1995 1:35 PM 
'geert (Geert Rosseel)' 
Re: euterpe power 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Wed Jan 4): 

Toplevel is in : /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards 
>From the -iter.stat file I see 553357 ISRCs. So I calculate 
553357*30/1 000000*3.3W nominal = 54.8W 
for the sofa. 

Right now I cannot seem to find the breakdown I had for the rest of 
the chip. Do you have a copy. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vo (Tom Vo) 

Wednesday, January 04, 1995 1:47 PM 
'Fred Obermeier' 
'geert (Geert Rosseel)' 

Re: tbr_euterpe-pass1 .spivs still no connections. 


Fred Obermeier wrote .... 
> 

>Tom, 
> 

>Could you take a look a /u/f wo/chip/euterpe/verilog/bsrc? For some 
reason 

>most of the xbcOl generators are not connected. Intermediate files 
should 

>Have been saved and the gmake log is FWO.errl. Do you think the 
unconnected 

>0/l generators is a problem with my setup or with euterpe? 
> 

>% grep -i nc2112 tbr_euterpe-passl . spivs 

>xrgxmituopapcenrqulOO vii6 nc2112 nc2113 vrr6_0 vrr6_l vrr6_2 

xbc01dfl6s 

> 

>% more tbr_euterpe-passl . csyn 

>/error 

> 

>error (FloatinglnputCheck. 1108) in file "tbr_euterpe-passl . spivs" : \ 

> input node has no driver and is not a top-level interface pin 
> 

> input 

> instance path: top . xdrmux4_13bankadul0 . dr_zeroa 

> cellname path: top .xbmux4dh2s .d2_ad0ph 

> topmost net 

> instance path: top . dr_zeroa 

> cellname path: top.dr_zeroa 


I think the problem is out of sync /u/chip/proteus/spice/leaf and /u/chip/proteus/ged/xb 
for the cOl generators . 

A while back , we deleted the resitor to generate the logicl output . 
/u/chip/proteus/spice/leaf still has the vrr associated with this resistor , but 
/u/chip/proteus/ged/xb does not . 


> 


> . . . 


> 


> Thanks, 
>Fred. 


> 


tvo 
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From: 
Sent: 
To: 

Subject: 


billz (Bill Zuravleff) 

Wednesday, January 04, 1995 1:48 PM 
'euterpe' 

Cache misses use NB entries 


y'all, 


Fur asked me to recapitulate cache miss processing to those who make and use the 
simulator. 

Specifically, there was concern that cache miss processing may use more NB entries than 
expected. Here are some notes: 

1. Euterpe only processes one cache miss at a time. 

This is the time from when a miss is detected, until the last hexlet is returned from 
backing store, is written into the Data array and the tag is updated. 
If there is a cache miss in another thread during this time it is simply replayed 
(hiccups) . 

2. A clean cache miss is interpreted by the cache controller as a request for 4 hexlets, 
which are in turn issued to the NB. The fastest these will be issued to the NB is one per 
10 ticks, i.e. as fast as loads can be issued from a single thread. 

3. A dirty cache miss will similarly cause 4 hexlet loads to be issued to the NB, but 
first, 4 hexlets are read out of the Data array -- the dirty data -- and sent as hexlet 
stores to the NB. 

The fastest these will be issued to the NB is one per 2 0 ticks, i.e. as fast as stores can 
be issued from a single thread. 

4. Load and Store requests from the cache controller to the NB are *low priority* (recall 
between all and none of the 16 NB entries are designated low priority, setable by a 
Cerberus register). If there is no low priority entry available -- the request is 
rejected the cache controller simply retries the request, indefinitely, on a 10 tick 
beat 

(loads) or a 20 tick beat (stores) until all requests are accepted. 

Thus for a dirty cache miss, cache miss requests can use up 8 low priority NB entries -- 4 
for stores, 4 for loads. 

We discussed ways to reduce number of NB entries a cache miss may use; essentially 
creating a lower- than- low priority level within the NB with the number of lower- than- low 
priority entries being either a small fixed number, 1 or 2 , or Cerberus register settable. 
We concluded that we have neither atoms nor time to implement these addtional features. 

Flame me if I'm lying. 


Sincerely, 
billz 
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From: fwo (Fred Obermeier) 

Sent: Wednesday, January 04, 1995 2:03 PM 

To: 'geert'; Vo* 

Cc: 'fwo' 

Subject: Re: tbr_euterpe-pass1 .spivs still no connections. 


Torn, 

Thanks for taking a look at the unconnected xbcOl generators in my tbr_euterpe- 

passl. spivs. - I presume that either you or Geert will take care of this. Could whomever 

fixes this let me know when to try and rebuild tbr_euterpe-passl . spivs again? 

Thanks , 
Fred. 
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From: 


tbr 


To: 


Subject: 


Sent: 


Wednesday, January 04, 1995 3:17 PM 
'bobm' 

forwarded message from Bill Zuravleff 


Follow Up Flag: Follow up 
Flag Status: Red 

Is there anything new here we should add to the doc? 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["2021" "Wed" "4" "January" "95" "1 1 :47:39" "PST" "Bill Zuravleff "billz " nil "49" "Cache misses use NB entries" 
" A From:" nil nil "1"]) 
Return-Path: <billz> 

Received: from melpomene.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA02343; Wed, 4 Jan 95 1 1:47:42 PST 
Received: from localhost by melpomene.microunity.com (8.6.4/muse-sw.3) 

id LAA25428; Wed, 4 Jan 1995 1 1:47:40 -0800 
Message-Id: < 19950 1041 947.LAA25428@melpomene.microunity.com> 
X-Mailer: ELM [version 2.3 PL 1 1 j 
From: billz (Bill Zuravleff) 
To: euterpe 

Subject: Cache misses use NB entries 
Date: Wed, 4 Jan 95 1 1 :47:39 PST 

y'all, 

Fur asked me to recapitulate cache miss processing to 
those who make and use the simulator. 

Specifically, there was concern that cache miss processing may 
use more NB entries than expected. Here are some notes: 

1 . Euterpe only processes one cache miss at a time. 
This is the time from when a miss is detected, until the 
last hex let is returned from backing store, is 

written into the Data array and the tag is updated. 
If there is a cache miss in another thread during this 
time it is simply replayed (hiccups). 

2. A clean cache miss is interpreted by the cache controller 
as a request for 4 hex lets, which are in turn issued to the 
NB. The fastest these will be issued to the NB is one per 
10 ticks, i.e. as fast as loads can be issued from a single 
thread. 

3. A dirty cache miss will similarly cause 4 hexlet loads 
to be issued to the NB, but first, 4 hex lets are read out 

of the Data array — the dirty data - and sent as hexlet stores to the NB. 
The fastest these will be issued to the NB is one per 20 
ticks, i.e. as fast as stores can be issued from a single 
thread. 

4. Load and Store requests from the cache controller to 
the NB are *low priority* (recall between all and none 
of the 16 NB entries are designated low priority, setable 
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by a Cerberus register). If there is no low priority entry 
available - the request is rejected ~ the cache controller 
simply retries the request, indefinitely, on a 1 0 tick beat 
(loads) or a 20 tick beat (stores) until all requests are 
accepted. 

Thus for a dirty cache miss, cache miss requests can 

use up 8 low priority NB entries — 4 for stores, 4 for loads. 

We discussed ways to reduce number of NB entries a cache miss 
may use; essentially creating a lower-than-low priority level 
within the NB with the number of lower-than-low priority entries 
being either a small fixed number, 1 or 2, or Cerberus register 
settable. We concluded that we have neither atoms nor time 
to implement these addtional features. 

Flame me if I'm lying. 

Sincerely, 
billz 

End of forwarded message 
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From: chip (Buffalo Chip) 

Sent: Wednesday, January 04, 1995 3:30 PM 

To: 'tbr' 

Subject: output of proteus/ikos/lib/.checkoutrc 

Wed Jan 4 13:24:08 PST 1995 (tbr Wed, 4 Jan 1995 12:39:47 -0800) proteus/ikos/lib 
[Release BOM (VI 7.0) in proteus/ikos/lib (Wed Jan 4 13:24:08 PST 1995)] 

Dir proteus/ikos/lib BOM 17.0 

l.l .checkoutrc 

1.14 Makefile 

1 .6 bufjde.pl 

l.l buf__pin.pl 

1.4 rT_lde.pl 

1.1 ff_pin.pl 

1.3 gate_Ide.pl 

1.1 gate_pin.pl 

1 .3 tgate_lde.pl 

1 . 1 tgate_pin.pl 

Dir proteus/ikos/lib/ikoscells.lde BOM 3.0 

1.1 ikoscells.cgbl 

1.2 ikoscells.gbl 

Dir proteus/ikos/lib/ikosrams.dwg BOM 2.0 

1 . 1 pin_gen 

1.1 ramtm-l.dwg 

1.1 ramtm-l.ps 

1.1 ramtm-2.dwg 

1 . 1 ramtm-2.ps 

1.1 ramtm-3.dwg 

1.1 ramtm-3.ps 

1.1 ramtm-4.dwg 

1.1 ramtm-4.ps 

1.1 ramtm-5.dwg 

1.1 ramtm-5.ps 

1.1 spram.dwg 

Dir proteus/ikos/Lib/ikosrams.fdt BOM 2.0 

1 . 1 lramcore.fdt 

1 . 1 ramtime.fdt 

1 . 1 spcore.fdt 

Dir proteus/ikos/lib/ikosrams.ldt BOM 4.0 

1.2 bram.ltt 

2.1 ce_stimrom.ltt 

1.2 ikosrams.gbl 
1.1 lramcore.ldt 
1.1 memlib.ver 
1.1 ramtime.ldt 
l.l ramtime.ltt 
1,1 spcore.ldt 
1.1 spram.ltt 

Dir proteus/ikos/lib/ikosrams.pit BOM 4.0 

1.3 allram.ptt 
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1.1 lramcore.pit 
1.1 ramtime.pit 
1 . 1 spcore.pit 

Dir proteus/ikos/lib/ikoszdra.dwg BOM 2.0 

1.1 spram.dwg 

1.1 sramtime-l.dwg 

1.1 sramtime-l.ps 

1 . 1 sramtime-2.dwg 

1 . 1 sramtime-2.ps 

Dir proteus/ikos/lib/ikoszdra.fdt BOM 2.0 

1 . 1 Iramcore.fdt 
1 . 1 spcore.fdt 
1.1 sramtime.fdt 

Dir proteus/ikos/lib/ikoszdra.ldt BOM 2.0 

1.1 bram.ltt 

1.1 ce_stimrom.ltt 

1 . 1 ikoszdra.gbl 

1.1 lramcore.ldt 

1.1 spcore.ldt 

1.1 sram.ltt 

1.1 sramtime.ldt 

Dir proteus/ikos/lib/ikoszdra.pit BOM 3.0 

1 . 1 lramcore.pit 
1.1 spcore.pit 
2. 1 sram.ptt 
1.1 sramtime.pit 

===> running proteus/ikos/lib/.checkoutrc (Wed Jan 4 13:24:38 PST 1995) <=== 
mkdir -p ikoszdra. lde 

cp ikoszdra.ldt/ikoszdra.gbl ikoszdra.lde/ikoszdra.gbl 

IKOSLIB=. LM_LICENSE_FILE=/n/auspex/sl8/chip-proteus/tools/vendor/ikos/voyager_2.0/voyager_license.dat 
VOYAGER_HOME=/n/auspex/sl8/chip-proteus/tools/vendor/ikos/voyager_2.0 IKOSTMP=ikostmp 
IKOSCONF=/n/auspex/s 1 8/chip-proteus/proteus/ikos IKOSLIB=/n/auspex/s 1 8/chip- 

proteus/tools/vendor/ikos/voyager_2.0/lib IKOSB^/n/auspex/slS/chip-proteus/tools/vendor/ikos/voyage^.O/sys/etc 
IKOSERR=/n/auspex/s 1 8/chip-proteus/tools/vendor/ikos/voyager_2 .0/sys/etc VO Y AGER_MACHINE=sun_sparc 
IKOSRAMTMPHkostmp work=dls_work dls_work= std=dls_std dls_std=/n/auspex/sl8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/lib/vhdl/sun_sparc/std ikos^dls ikos dIs_ikos=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/lib/vhdl/sun_sparc/ikos ieee=dls_ieee dls_ieee=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/lib/vhdl/sun_sparc/ieee PATH=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/bin/sun_sparc:$PATH /n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/bin/sun_sparc/ramgen ikoszdra ce ! 

stimrom -p ce stimrom 
reading in the lookup table 
getting info from libcells.add 
beginning to install cells 
cell number 0 

the cell is lramcore-ce_stimrom and the file is 1ml 8998. lde 

fault cell id is 1 

done restoring 

Getting the resolution... 

Reading in the pinlist... 

Calculating delay values... 

Creating simulation files... 

Installing the cell into ikoszdra... 

Installing into fault library... 

saved 

cell number 1 

the cell is sramtime-ce_stimrom and the file is sm 1 585 1 .lde 
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fault cell id is 1 
done restoring 
Getting the resolution... 
Reading in the pinlist... 
Calculating delay values... 
Creating simulation files... 
Installing the cell into ikoszdra... 
Installing into fault library... 
saved 

2 out of 2 cells compiled successfully 
there were 0 errors or warnings logged 
we are done 

parsing /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.ldt/ce stimrom.ltt 
A -0 15 1 
D =0 151 1 

parsing /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.ldt/lramcore.ldt 
tagged cellname = lramcore-ce_stimrom 

Ide for .gbl is /N/auspex/root/s 18/chip-proteus/ikos/lib/./ikoszdra.lde/ikoszdra.gbl ldt for .gbl is /N/auspex/root/s 1 8/ch ip- 
proteus/ikos/lib/./ikoszdra.ldt/ikoszdra.gbl 

expanding /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.pit/lramcore.pit to /N/auspex/root/s 1 8/ch ip- 
proteus/ikos/lib/./ikoszdra.pin/lm 1 8998.pin 
expanding genram.tmp/lramcore.tde to genram.tmp/lml8998.1de 

A =015 1 

D -0 151 1 

parsing /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.ldt/sramtime.ldt 
tagged cellname = sramtime-ce_stimrom 

expanding /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.pit/sramtime.pit to /N/auspex/root/s 1 8/ch ip- 
proteus/ikos/lib/./ikoszdra.pin/sm 1 585 1 .pin 
expanding genram.tmp/sramtime.tde to genram.tmp/sm 15851. Ide 
parsing /N/auspex/root/s 1 8/chip-proteus/ikos/lib/./ikoszdra.Idt/ce_stimrom . Itt 
A -0 15 1 
D =0 151 1 

expanding genram.tmp/toptagd.ptt to genram.tmp/sram.pin 
Genlibing... 

cd ikostmp; for i in "cat ../libcells.add'; do \ 

IKOSLIB=. LM_LICENSE_FILE=/n/auspex/sl8/chip-proteus/tools/vendor/ikos/voyager_2.0/voyager_Iicense.dat 
VOYAGER_HOME=/n/auspex/s 1 8/chip-proteus/tools/vendor/ikos/voyager_2.0 IKOSTMPHkostmp 
IKOSCONF=/n/auspex/sl 8/chip-proteus/proteus/ikos IKOSLIB=/n/auspex/sI 8/chip- 

proteus/tools/vendor/ikos/voy ager_2.0/lib IKOSB=/n/auspex/s 1 8/chip-proteus/tools/vendor/ikos/voy ager_2 .0/sys/etc 
IKOSERR=/n/auspex/sl8/chip-proteus/tools/vendor/ikos/voyager_2.0/sys/etc VOYAGER_MACHINE=sun_sparc 
IKOSRAMTMP= ikostmp work=dls_work dls_work= std=dls_std dls_std=/n/auspex/sl 8/chip- 
proteus/tools/vendor/ikos/voyager_2.0/lib/vhdl/sun_sparc/std ikos=dls_ikos dls_ikos=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager 2.0/1 ib/vhdl/sun_sparc/ikos ieee=dls_ieee dls_ieee=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager_2 .0/lib/vhdl/sun_sparc/ieee P ATH=/n/auspex/s 1 8/chip- 
proteus/tools/vendor/ikos/voyager 2.0/bin/sun_sparc:$PATH /n/auspex/sl8/chip- 
proteus/tools/vendor/ikos/voy ager_2 .0/bin/sun_sparc/ldex -1 ikoszdr! 
a-f$i.lde;\ 

awk -f .. /ikoszdra. sh/ldecon v. awk Si.lde > .. /ikoszdra. lde/$i. Ide; \ 

done 

Translating '../ikoszdra.lde/lml8998.1de\.. 
Generating next generation Ide file '1m 18998. Ide'... 
Reading '.. /ikoszdra. fle/lm 1 8998.fle'... 
Adding fie data... 

End translating! 1796 lines are translated 

ALCHEMY Ldex Version 1.00 (c) 1993 IKOS SYSTEMS, INC 

awk: can't open /ikoszdra. sh/ldeconv. awk 

Translating ' . ./ikoszdra. Ide/sm 15851. Ide'... 
Generating next generation Ide file 'sm 158 51. Ide'... 
Reading '.. /ikoszdra. fle/sm 1 585 1 .fie'... 
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Adding fie data... 

End translating! 3859 lines are translated 

ALCHEMY Ldex Version 1 .00 (c) 1993 IKOS SYSTEMS, INC 

awk: can't open ,./ikoszdra.sh/ldeconv.awk 
gmake: *** [ikoszdra.mac/ce_stimrom,pin] Error 2 
[finished at Wed Jan 4 13:29:50 PST 1995 - exit status 1] 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, January 04, 1995 3:36 PM 

To: 'billz'; 'jeffm' 

Cc: 'woody'; 'tbr' 

Subject: storetiny dump 


Is in /n/nosferatu/s2/euterpe/verilog/bsrc/storetiny_0.* 
Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Raymond R. Hayes [hayes@MicroUnity.com] 
Wednesday, January 04, 1995 7:09 PM 
'abbott (Curtis Abbott)' 

'guarino@MicroUnity.com'; 'kgk@MicroUnity.com*; Alexia Massalin; 

'vandyke@MicroUnity.com' 

Re: Type safety in the Terp compiler.... 


> Anyway, what I really want to do is bring up another issue, as long as 

> we're talking compiler directions. Late last year (i.e. 2 weeks ago) 

> I talked with Don about making the compiler return structs in 4 and 

> maybe even 8 registers. 

This is pretty easy to do, but does not provide the functionality you desire unless 
"structure coloring" is also implemented. There is a point in the compiler where, 
ideally, memory references for every object which can reside solely in a register are 
removed. At first, this was done for non- aggregate locals which had not had their 
addresses taken,- then it was also applied to non-aggregate globals. Eventually, it will 
be applied to aggregates and anonymous address expressions. Finally., it will be applied 
to objects which have had their addresses taken; it is necessary to compute regions over 
which these objects may be externally visible in order to decide whether they need to be 
written to memory. 

> I realized a few days ago that if I could pass a struct ptr, 

> dereference it in the static inline and have the compiler keep it in 

> registers, that would be much better for me. Currently, that does not 

> appear to work. (See ~abbott/design/dsp/pulsetest . c for the example I 

> tried it 

> on.) Can one of you discuss the issues here? 
There are a couple things going on here: 

- One of the fields of the structure is modified in the loop. This 
may cause the other structure fields to appear to vary, preventing 
them from being hoisted and adding 5 loads to the body of the loop . 

- "Structure coloring" will be necessary to eliminate the load and 2 

2 stores associated with the modified field; a load and a store are 
necessary if the structure is externally visible at the bottom of 
the loop . 

> Is this as good an idea 

> as it seems, or is there some fatal flaw I don't know about? 

I can't think of any fatal flaws, just lots of work which needs to be done to generate the 
most efficient code. In general, structures cause us the compiler problems because they 
can be accessed as aggregates or by component; currently, aggregate access can only really 
be provided through memory. Globals and anything which has had its address taken cause 
the compiler problems since memory is currently our only globally visible, shared 
resource; interprocedural register allocation will eventually help us here... 


Ray 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, January 04, 1995 8:01 PM 

To: 'jeffm' 

Cc: 'tor'; 'mws'; 'billz'; 'woody'; 'dickson' 
Subject: pagesize 


Jeff you dump of pagesize 

*** X CORRUPT: 800040 uu.vldlsDstR15[0]= x *** 

is on rhodan /s3/euterpe/verilog/bsrc/pagesize_0.* 
Lisa R. 
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From: Tom Eich [tbe@MicroUnity.com] 

Sent: Wednesday, January 04, 1995 8:41 PM 

To: 'tbf 

Cc: 'boxers'; 'aP 

Subject: Re: Power to the chips. 

Herman forwarded: 


>Herman Chu wrote (on Wed Jan 4): 

> 

> Hi Tim, 

> 

> The following are the only 2 mail that I can find that have any mentioned 
>of 

> the Eu power. However, I have quite a few email on the Ca power 

> evolution. 

> 

>Thanks. This is inline with what we knew though I do seem to have 
>lost the breakdown of the custom section. Based on the latest route 
>(which is now essentially complete), 1 calculate 65 W in the sofa at 
>nominal power (knob setting 6). We have between 20 and 21 W in the 
>custom area, so the total is looking like near 85W, up yet again I'm 
>afraid from the last guess of 73. I'll double check the custom 
structures, but I don't expect any change there. 
> 

>Tim 

> 

Some questions: 

1) Does this have any implications for the calculated Calliope power (last 
calculated at 54. 9 W)? I assumed not, but want now to make certain. 

2) The 85 W consumption above is stated for nominal power (knob setting 6). 
What is the likelyhood of going higher and what would be the maximum you 
expect in the worst-case? What is the best-case also? 

3) Are there any plans to spend resources on the problem of reducing the 
power consumption of the MobiMOS Euterpe this year? 


We need your input in order to understand where the increased power may 
leave the current Hestia design with respect to its product potential and 
the specifications, as well as to properly bound the packaging problem for 
Pandora. Unfortunately, the current Hestia design is tapped out wrt power 
dissipation capacity for realistic product environments (and Noel says it's 
nearly so wrt power supply capacity). 


Thanks, 
-Tom 
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Tom Eich | tbe@microunity.com 

MicroUnity Systems Engineering, Inc,| 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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From: tbr 

Sent: Wednesday, January 04, 1995 9:12 PM 

To: 'Tom Eich' 

Cc: 'al'; 'geert'; 'boxers' 

Subject: Re: Power to the chips. 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Eich wrote (on Wed Jan 4): 
Herman forwarded: 


>Herman Chu wrote (on Wed Jan 4): 

> 

> Hi Tim, 

> 

> The following are the only 2 mail that I can find that have any mentioned 
>of 

> the Eu power. However, I have quite a few email on the Ca power 

> evolution. 

> 

>Thanks. This is inline with what we knew though I do seem to have 
>lost the breakdown of the custom section. Based on the latest route 
>(which is now essentially complete), I calculate 65 W in the sofa at 
>nominal power (knob setting 6). We have between 20 and 2 1 W in the 
>custom area, so the total is looking like near 85 W, up yet again I'm 
>afraid from the last guess of 73. I'll double check the custom 
structures, but I don't expect any change there. 
> 

>Tim 


Some questions: 

1) Does this have any implications for the calculated Calliope power (last 
calculated at 54.9W)? I assumed not, but want now to make certain. 

No, no change there. 

2) The 85 W consumption above is stated for nominal power (knob setting 6). 
What is the likelyhood of going higher and what would be the maximum you 
expect in the worst-case? What is the best-case also? 

We would only turn the knob higher if there is a big difference in the 
process from the models. This does not necessarily mean more power if 
we are doing it because the devices are weaker than expected since the 
higher setting would just be to restore the nominal current levels. 
We may need to turn up isolated knobs if we have a few timing 
violations that slip through. There should be zero of these by 
design. The most we can do is turn the knob to 7 which would be 7/6 
of nominal, but as I say, that is likely to be only a few out of 30 or 
so knobs, so should be a very small effect, certainly less than 10%. 
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My number (as for the earlier ones) is assuming nominal 3.3 V power, so 
there is also a further 10% if we were operating at 3.6 V. 

3) Are there any plans to spend resources on the problem of reducing the 
power consumption of the MobiMOS Euterpe this year? 

We are putting effort into making sure the CMOS version will be 
portable to MOBI, where it should have much lower power than on the 
foundry process and probably significantly lower power than the 
bipolar Euterpe. It's too soon yet to tell though what power it is 
likely to come in at. However, we know for sure the CMOS version will 
not be near the performance we need for hestia, so it is unlikely to 
be a solution there. We need the power reduction and to retain the 
performance. 

We need your input in order to understand where the increased power may 
leave the current Hestia design with respect to its product potential and 
the specifications, as well as to properly bound the packaging problem for 
Pandora. Unfortunately, the current Hestia design is tapped out wrt power 
dissipation capacity for realistic product environments (and Noel says it's 
nearly so wrt power supply capacity). 

I will let geert comment further, but I think we have the circuit 
resources stretched to do the CMOS version on time, so it's unlikely 
to me we would be mounting a full scale effort on a wholly new bipolar 
circuit family in addition to make a major dent in this power by end 
of 1995. 

Tim 
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From: tbr 

Sent: Wednesday, January 04, 1995 9:20 PM 

To: 'torn'; 'brianl' 

Cc: 'geert 

Subject: snapshot build 

Follow Up Flag: Follow up 

Flag Status: Red 


I'm a bit worried about the snapshot build I started last night. 1 
thought it was busy doing timing stuff and indeed dealstatus says: 

deal status at Wed Jan 4 19:17:47 PST 1995 

from to user cmd# line started at command 

cyclops ambiorix chip 321 961 Wed Jan 04 19:04:48 echo Making mlt 

Cyclops ares chip 315 943 Wed Jan 04 18:52:11 echo Making mlt 

cyclops hera chip 288 862 Wed Jan 04 16:56:48 echo Making mlt 

cyclops kephalos chip 319 955 Wed Jan 04 19:00:09 echo Making mlt 

cyclops merope chip 326 976 Wed Jan 04 19:12:53 echo Making mlt 

cyclops narcissus chip 325 973 Wed Jan 04 19:12:50 echo Making mlt 

cyclops pegasus chip 322 964 Wed Jan 04 19:05:59 echo Making mlt 

cyclops pelorus chip 327 979 Wed Jan 04 19:15:08 echo Making mlt 

cyclops phobos chip 324 970 Wed Jan 04 19:09:30 echo Making mlt 

cyclops polyhymnia chip 323 967 Wed Jan 04 19:08:19 echo Making mlt 

cyclops psyche chip 328 982 Wed Jan 04 19:16:18 echo Making mlt 

cyclops thalia chip 320 958 Wed Jan 04 19:03:31 echo Making mlt 

with cyclops being the machine I started it from. However the logfail 
is 

tbr@aphrodite /n/auspex/s41/euterpe-snapshot/euterpe/proteus 409 % Is -Is maker 
rs 

29 -rw-r-r-- 1 chip 29615 Jan 4 02:14 makerrs 

which has not been touched in 15 hours. If I look at the end of the 
log I see: 

### finished with or5.pdl Wed Jan 4 02:13:11 PST 1995 

### doing distributed make on (kephalos psyche boreas phobos rimulac) - [ Wed Jan 4 02: 1 3: 1 1 PST 1995 ] 

# 

# divide the cell list among the available machines 

(echo tmp. list, kephalos tmp.list. psyche tmp.list.boreas tmp.list.phobos tmp. list rimulac; cat/n/auspex/s23/euterpe-proteus- 
cp/leafgen/list) \ 
| awk ' \ 
NR==1 {\ 

nf = NF;\ 

for (i = 0; i < nf; i++) { \ 
file[i] = $(i + 1); \ 

)\ 

>;\ 

NR > 1 { print > file[NR % nf] }' 

# 

# fire off an rsh on each machine, and wait 

for MACH in kephalos psyche boreas phobos rimulac; \ 
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do\ 

echo "cd 'abspatiY; \ 
nice -15 gmake -wk CELL_LIST=tmp.list.$MACH \ 

leaf-layouts > tmp.make.out.$MACH 2>&1" \ 
|rsh $MACH sh&\ 
sleep 10; \ 
done; wait 

which looks to me like the leaf cell layouts getting built, not the 
timing run. 

Can either of you figure out if it is in fact still doing the right 
thing? 

Thanks 
Tim 


Exhibit CIO 


Page 36 of 356 


From: tbr 

Sent: Wednesday, January 04, 1995 9:33 PM 

To: 'lisar' 

Subject: protection problem 

Follow Up Flag: Follow up 

Flag Status: Red 

Have you been running as you in my bsrc area (IKOS that is)? 
1 am getting: 

override protection 644 for 

/n/auspex/s 1 5/tbr/euterpe/verUog/bsrc/xs_dir/L^ 

and unfortunately saying y at that point does not help, it just hangs. 
Tim 
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From: Raymond R. Hayes [hayes@MjcroUnity.com] 

Sent: Thursday, January 05, 1 995 1 :27 AM 

To: 'abbott (Curtis Abbott)' 

Cc: 'vandyke@MicroUnity.com' 

Subject: Re: upgrades to static inlines 


> I just had a followup conversation with Ray about his response to my 

> mail. He pointed out there's still another style --of passing 

> pointers to state vars . I think passing structs may be the optimal 

> thing stylistically, but passing pointers is good too. 

Here's a pretty wacky observation. When a pointer to the struct is passed and a field of 
the struct is modified in the loop, all of the fields of the struct look as if they vary. 
If the value of the field to be modified is assigned to a local and the address of that 
local is passed as well, no struct field is modified in the loop, so all the struct field 
accesses look invariant and are hoisted out of the loop! Check out the C code appended to 
this message . . . 

> Ray thought it 

> was pretty easy -- something to do with where the associate bit gets 

> set . 

The associated bit problem is still there. When INLINE_FOO is not defined, the compiler 
can't tell that the modified local is not ex- ternally visible; so the load and store 
associated with the modified local cannot be eliminated. 

There are still a few problems/ most notably the dead stores in the structure set-up code; 
however, the rest of the code looks great, especially when INLINE_F00 is defined and the 
memory references as- sociated with the modified local can be removed. 

Ray 


^include <types.h> 
#include <terp/builtins . h> 

struct pulses_state 

< 

int accum; 
packed_int8 onvals; 
packed_int8 starts; 
packed_int8 stops; 
packed_int8 incrs; 

int interval; /* oncount+off count */ 

}; 

#if defined (INLINEFOO) 
extern short a; 

static inline void f oo (packed_int8 x) 

{ 

a += hi64 (x) ; 

} 

#endif 

static inline packed_int8 

pulses_8{int *p_accum, struct pulses_state *p) { 
packed_int8 tmp; 
int accum = *p_accum + 16; 

packed_int8 onvals = p->onvals, starts = p->starts; 
packed_int8 stops = p->stops, incrs = p->incrs; 
int interval = p-> interval; 
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tmp = gadd8 (incrs, gcopy8 (accum) ) ; 

tmp = gsetge8(tmp, starts) & gsetl8 (tmp, stops); 

*p_accum = emux (SET_MASK (accum >= interval), accum - interval, accum); 
return onvals & tmp; 


main( ) 
{ 

struct pulses_state p; 
packed_int8 retl, ret2 ; 
int i; 

int p_accum; 


p_accum = p. accum = 0; 

p. onvals = gcopy8 (0x10) ; 

p. starts = gcopy8 (0x28) ; 

p. interval = 0x31; 

p . stops = gcopy8 (p . interval ) ; 

p. incrs = OxOf 0e0d0c0b0a09080706050403020100 ; 

for (i = 0; i < 8; i++) { 

retl = pulses_8 (&p_accura, &p) ; 
ret2 = pulses_8 (&p_accura, &p) ; 
foo(retl * ret2) ; 

} 

p. accum = p_accum; 

} 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, January 05, 1 995 1 :39 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/au BOM 25.0 initiated by dickson completed @ Wed Jan 4 
23:35:19 PST 1995 with exit status 0.. chip 
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From: billz (Bill Zuravleff) 

Sent: Thursday, January 05, 1995 12:23 PM 

To: 'torn (Thomas Laidig)'; 'doi (Derek Iverson)' 

Cc: 'tbr (Tim B. Robinson)'; 'dickson (Richard Dickson)'; 'mws (Mark Semmelmeyer)'; 'geert (Geert 

Rosseel)'; 'woody (Jay Tomlinson)' 
Subject: releaesbom problem 


y all, 

ASAConveniently Possible could either of y'all give me some help with releasebom. 
Problem symptom: releasebom begins releasing BOM is subdirectories, then stops with no 
diagnostic messages. I'm trying to release BOM 199 in euterpe/verilog/bsrc . 

Thanks , 
billz 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, January 05, 1995 12:31 PM 

To: 'geert@rhea' 

Subject: pager log message 

page from chip to geert : 

Release euterpe/verilog/bsrc/hz BOM 15 . 0 initiated by dickson completed @ Thu Jan 5 
10:27:45 PST 1995 with exit status 0.. chip 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Thursday, January 05, 1995 1:08 PM 
'karzes@tallis' 

'softwa re@tal I is ' ; 'eu te rpe@ta 1 1 is' 
gextract 


I got to thinking about your comments last night about the code I'd written for extracting 
aligned hexlets from a bizarrely organized frame buffer. 

I realized that the instruction pair we talked about can be adapted to do a number of 
things, including a 2-issue-slot gextractl28 and a 2-issue-slot non- immediate gextractN 
for N<128. In the first case, this improves on the hardware implementation w.r.t. issue 
slots; in the second case, it provides an instruction that isn't in the hardware in the 
same number of issue slots as the immediate version that is. 

This may be particularly relevant for gextractl28, since we have quite a few of these in 
inner loops. It is not uniformly better than the hardware implementation, since it uses 2 
instructions and has a latency of 4 (vs 3), but we are usually issue-slot limited in inner 
loops, so it will usually be better there. 

To do gextractl28 (hi, lo, sh) : 

gmshrl28 (grotrl28 (hi, sh) , lo, sh) ; 

To do gextract64 (hi , lo, sh) : 

gmshr64 (grotr64 (hi , sh) , lo, sh) ; 


And so on. 


Cool, no? 


- Curtis 
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From: Mark Semmelmeyer [mws@tallis] 

Sent: Thursday, January 05, 1 995 1:40 PM 

To: 'karzes^taliis'; 'abbott@tallis' 

Cc: 'software@tallis'; 'euterpe@tallis' 

Subject: Re: gextract 


> From abbott@tallis Thu Jan 5 11:08:01 1995 

> a 2 -issue- slot gextractl28: 

> this improves on the hardware implementation w.r.t. issue slots. 

> It is not uniformly better than the 

> hardware implementation, since it uses 2 instructions and has a 

> latency of 4 (vs 3) , 

If EAddl is latency 1, then EShLI is latency 2, and a 3 issue step op like gextractl28 in 

hardware would be latency 4 . 

Then your only penalty is code space. 

> but we are usually issue-slot limited in inner loops, so it will 

> usually be better there. 
> 

> To do gextractl28 {hi , lo, sh) : 

> gmshrl28 (grotrl28 (hi, sh) , lo, sh) ; 

I am assuming that the compiler or some tool will stuff something useful into the issue 
slot otherwise wasted between the grotr and gmshr above and created by the XLU-use 
dependency. Otherwise the effective issue slots available is the same as the hardware 
implementation . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Scott Furman [fur@quetzalcoatl] 
Thursday, January 05, 1995 1:44 PM 
'Curtis Abbott' 

'karzes@taHis'; 'software@tallis'; 'euterpe@tallis' 
gextract 


I didn't CC this correctly the first time. Apologies to those who receive two copies. 


Curtis Abbott writes: 

> I got to thinking about your comments last night about the code I'd > written for 
extracting aligned hexlets from a bizarrely organized > frame buffer. 

> 

> I realized that the instruction pair we talked about can be adapted to > do a number 
of things, including a 2- issue- slot gextract 128 and a > 2 -issue- slot non- immediate 
gextractN for N<128. In the first case, > this improves on the hardware implementation 
w.r.t. issue slots; in > the second case, it provides an instruction that isn't in the 
hardware > in the same number of issue slots as the immediate version that is. 


This is not quite the same as a gextractl28 because of the recent change which causes a 
shift count of 128 to be different from a shift count of 0. (What you have emulated with 
your two- instruction sequence is the "old" gextractl28 . ) Nonetheless, these are good 
observations, particularly for the gextractl28 ' s . (I personally have found only rare uses 
for non- immediate gextracts with size less than 
128.) 

> This may be particularly relevant for gextractl28, since we have quite > a few of 
these in inner loops. It is not uniformly better than the > hardware implementation, 
since it uses 2 instructions and has a > latency of 4 (vs 3), but we are usually issue- 
slot limited in inner > loops, so it will usually be better there. 

Something seems fishy here. The current gextractl2 8 implementation takes three issue 
slots and has latency *four* (as described by mws on 

10/26/93 and implemented in the simulator) . Yet, we can command the hardware to produce 
almost the same result using two issue slots. (I say "almost" because of the special-case 
shift count of 128) . It seems like the microcoded gextractl28 instruction ought to be 
able to do as well. I wonder what Tom has to say on this matter. 


-Scott 
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From: 
Sent: 
To: 

Subject: 


Scott Furman [fur@quetzalcoatl] 
Thursday, January 05, 1995 1:47 PM 

'Curtis Abbott'; 'karzes@tallis'; 'software@tallis'; 'euterpe@tallis' 
gextract 


Scott Furman writes: 

> Something seems fishy here. The current gextractl28 implementation 

> takes three issue slots and has latency *four* {as described by mws on 

> 10/26/93 and implemented in the simulator) . Yet, we can command the 

Off -by-one error. Obviously, I meant that our discussion took place on 10/26/94. 


-Scott 
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From: torn (Tom Laidig) 

Sent: Thursday, January 05, 1995 1:57 PM 

To: Bill Zuravleff 

Cc: 'doi (Derek Iverson)'; 'tbr (Tim B. Robinson)'; 'dickson (Richard Dickson)'; 'Mark Semmelmeyer'; 
'Geert Rosseel'; 'Jay Tomlinson'; Thomas Laidig' 

Subject: Re: releaesbom problem 

Bill Zuravleff writes: 

I 

ly'aii, 

| ASA Conveniently Possible could either of y'all give me some 
jhelp with releasebom. Problem symptom: releasebom begins 
jreleasing BOM is subdirectories, then stops with no 
jdiagnostic messages. I'm trying to release BOM 199 in 
| euterpe/veri 1 og/bsrc . 

I've just done some sanitizing of the repository, removing old #cvs.* 
files (which are cvs's lock files). Try it now... 


ooooO Ooooo 
(JO 

\( tau )/ 
O O 
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From: 
Sent: 
To: 

Subject: 


chip (Buffalo Chip) 

Thursday, January 05, 1995 4:13 PM 
'billz' 

output of euterpe/verilog/bsrc/cc/.checkoutrc 


The output from euterpe/verilog/bsrc/cc/ . checkoutrc is 280k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/billz . ghidra. 27411 . euterpe-verilog-bsrc-cc 

(which is accessible from all machines)- This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: chip (Buffalo Chip) 

Sent: Thursday, January 05, 1995 4:32 PM 

To: 'billz' 

Subject: output of euterpe/verilog/bsrc/.checkoutrc 

Thu Jan 5 14:27:41 PST 1995 {billz Thu, 5 Jan 1995 13:36:20 -0800) euterpe/verilog/bsrc 
[Release BOM (V199.0) in euterpe/verilog/bsrc {Thu Jan 5 14:27:42 PST 1995)] 

BOM 199.0 


Dir 

euterpe/verilog/bsrc 

32 . 7 

. checkout rc 


73 . 1 

lcesnk.ut 


116 . 1 

ldr basic. ut 


1 . 191 

Makefile 


(1.188) 



1. 52 

Makefile . share 


40.39 

Makefile. tst 


27.14 

Makef ile . vo 


27. 11 

TODO 


68 . 5 

a_euterpe_wrap 

parm 

35.3 

analog_euterpe 

hwc 

183 . 2 

ceuterpe_wrap 

parm 

35.3 

clockbias .hwc 


68 . 3 

d_euterpe_wrap 

parm 

80. 5 

dcells .pif 


7 . 1 

doexcldlist 


80. 1 

dummy .rcf 


6. 332 

euterpe . V 


(6 . 325) 



12 . 6 

euterpe . conf ig 


24 .20 

euterpe. status 


6.76 

euterpe_driver 

V 

6 .29 

euterpe_pads . V 


15. 63 

euterpe_wrap . V 


(15 . 61) 



15 .4 

euterpe_wrap . parm 

134 .4 

export_obs 


119.4 

export subblock 

20.1 

fake .pi 


41.10 

genpim2 .pi 


(41 . 9) 



47 . 9 

gettst 


65 . 2 

h_euterpe_wrap 

parm 

12 . 1 

hwc nets 


187 . 2 

i_euterpe_wrap 

tb 

187 . 5 

i_euterpe_wrap 

vhdl 

91. 3 

levellog 


134 . 2 

levelmlog 


1.17 

op chart 


37.6 

pimlib.pl 


(37.5) 



131.3 

preptest 


70.3 

purgetst 


(70.2) 



131.1 

runS 


134.3 

runvtest 


62. 10 

stashtst 


40.4 

subblk. rcf 


52 . 5 

tbr3_v2e . conf ig 

35.1 

toplev . power . tab . local 

41.5 

toplev. rcf 


12.2 

tst_v2e . conf ig 


Dir 

euterpe/verilog/bsrc /at 


BOM 37.0 


Exhibit C10 


Page 49 of 3 


4.1 . checkoutrc 
1 . 9 Makefile 
1.28 at.V 

1.5 at . h 

2 8.3 at . power . tab . top 

3 . 11 at_control . pirn 

1.2 atcdwe2.pla 
1.1 atcteql.pla 

1.1 atcylenc.pla 

1.3 atdisallowxc .pla 
25.1 atgtlbcnf let . Veqn 

1 . 4 atgtmissxc . Veqn 

2 . 1 a t nbreq . Veqn 
1 . 14 atpaded . Veqn 

1 . 2 atpaselgen2 . Veqn 
1 . 1 atpaselgen64 . V 
1.1 atpaselgen8 . Veqn 
1.11 atprchk . Veqn 

1 . 1 atvabyp . Veqn 

1.2 atxcenbl.pla 

1.1 atxcfrz.Veqn 
4 . 2 clean-request 

1.2 genatcteql58.pl 
1 . 1 genatpasel .pi 

3.5 genpim.pl 

3 . 1 genptab . pi 
3.7 pimlib.pl 

Dir euterpe/verilog/bsrc/au BOM 25.0 

14.1 .checkoutrc 
1.9 Makefile 

16.5 au. power. tab. top 
1.17 auindx.V 

12.6 auindx . pirn 
14.4 clean- request 

12.4 genpim.pl 
12 . 1 pimlib.pl 

14.3 power . tab. local 

Dir euterpe/verilog/bsrc/cc BOM 40.0 

9.1 . checkoutrc 

1.14 Makefile 

1.45 cc.V 

23.13 cc.pim 

32.2 cc .power . tab. top 

I. 11 cc.ut 

5 . 9 cc_control .pim 

28.3 cccount.pla 
28.2 cchexcount .pla 

28.7 ccseq.Veqn 

II. 11 ccsm.pla 
24.2 ccstart.Veqn 
1.11 cctester.V 
1.1 cctester.h 

14.8 clean- request 
5.9 genpim.pl 

5.6 pimlib.pl 

5.1 power . tab. local 

Dir euterpe/verilog/bsrc/cdio BOM 3 9.0 

19.8 . checkoutrc 

1.11 Makefile 

1.16 cdio.V 

34.5 cdio .power . tab. top 
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7.1 cdio.ut 

2 8.3 cdio_control .pirn 

25.5 clean-request 

7 . 5 genpim . pi 

3.10 genptab.pl 

7.11 pimlib.pl 

Dir euterpe/verilog/bsrc/ce BOM 59.0 

1.14 Makefile 

1.8 Makef ile.gards 

1.1 ce . conf ig 
2.13 ce cms2ecl.V 
(2.12) 

2.11 ce_flash.V 
17.5 ce_kybd.V 

17.3 ce_kybdcntr . V 
32.5 ce_mck.V 
(32.4) 

2 . 7 ce_seg7 .V 

1 . 5 ceclockbiasbuf . V 

1.13 cecore.V 

1.2 cedmctrl.V 

1.4 cedmctrlm.V 

1.2 cedmctrlt.V 

1.8 cedpreg.V 
1.1 celoosends.V 

1.9 cemaster.V (1.8) 

1.6 cerb.in 

1.6 cerbctrlreg. v 
1.43 cerberus.V 
(1.42) 

1.14 cerberus . cpif 

1.3 cerberus. rcf 

1 . 5 cerbnobreg . V 

1.4 cerbskewreg. v 

1.7 cerbtempreg. V 

1.3 4 cerbtest.V 

1.5 ceregbuf.v 
1.26 ceregcore.V 
1.13 ceslave.V 

1.4 cetstmux.V 

Dir euterpe/verilog/bsrc/cg BOM 9.0 

1.8 Makefile 

Dir euterpe/verilog/bsrc/cj BOM 86.0 

4 6.4 . checkoutrc 

18 .2 libr.ut 

18.2 liss.ut 

1.35 Makefile 

2.12 br.tst 
1.17 cj.V 
1.3 cj.h 

62.5 cj.pim 

6 9.8 cj .power . tab. top 

13 .25 cjrst.tst 

48.7 clean-request 

I. 8 freel.tst 
4 2.2 genpim.pl 
4 7.5 genptab.pl 

II. 16 hic.tst 
1.12 hold.tst 
3.16 if br.tst 

23.6 ifpred3-ll.tst 

20.4 ifpred3-2.tst 
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5.24 

micbr . t st 

5.12 

pcbhnd. tst 

42 . 3 

pimlib.pl 

78 .1 

rsrvd. tst 

Dir 

euterpe/verilog/bsrc/ck 

10 . 3 

. checkout rc 

1 . 8 

Makefile 

9.2 

ck.V 

17 .4 

ck . power . tab . top 

1 . 3 

cktop . V 

11 . 1 

clean 

12 .2 

clean- request 

10.2 

genpim.pl 

10.5 

pimlib.pl 

Dir 

euterpe/verilog/bsrc/cp 

9 . 3 

. checkoutrc 

1 . 7 

Makefile 

9.4 

clean- request 

1.23 

cp.V 

(1 .24) 


7 . 12 

cp.pim 

(7.13) 


19. 5 

cp . power . tab . top 

5.6 

genpim.pl 

5.2 

pimlib .pi 

5.10 

power . tab . local 

Dir 

euterpe/verilog/bsrc/ctiod 

1 . 2 

. checkoutrc 

1 . 6 

Makefile 

7 . 1 

bram . init 

1 . 5 

clean- request 

7.1 

ctd. in 

1.3 

ctiod.V 

12 .4 

ctiod. power . tab. top 

6 . 2 

ctiod.ut 

1 . 3 

ctiodtester . V 

6 . 1 

ctiodtester ,h 

1 . 3 

ctwe . Veqn 

1 . 1 

genpim.pl 

1.5 

genptab .pi 

1.6 

pimlib.pl 

Dir 

euterpe/verilog/bsrc/ctioi 

3 . 1 

. checkoutrc 

1.4 

Makefile 

4 . 3 

clean- request 

1 . 8 

ctioi . V 

1 . 3 

ctioi .pirn 

9 . 5 

ctioi . power , tab . top 

1.1 

genpim.pl 

1 . 1 

pimlib . pi 

4.5 

power . tab . local 

Dir 

euterpe/verilog/bsrc/dp 

1.31 

Makefile 

1.37 

dp . V 

1.29 

dptop. V 

29.3 

dpwrap . V 

13 .10 

mstepc . V 
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Dir 


euterpe/verilog/bsrc/dr 


BOM 51.0 


32 . 3 

. checkoutrc 

1 .27 

Makefile 

1 . 4 

README 

33.5 

clean- request 

12 . 1 

clocksub 

1 .19 

dr . V 

1 . 1 

dr. clocks .ut 

1 . 13 

dr . conf ig . h 

46 .2 

dr .pirn 

43 . 2 

dr . power . tab . top 

1 . 9 

dr .ut 

1 . 2 

dram . registers 

1 . 1 

drba .pi a 

7 . 9 

drbank . V 

1 . 6 

drbanka rb . p 1 a 

1 . 3 

drbankcsm . pi a 

3 . 5 

drbanksel . Veqn 

1 . 3 

drcd.pla 

1.2 

drclockphase .pla 

1 . 2 

drcolscram . pla 

4 . 3 

drconf ig2bs . pla 

1 . 3 

drcsm. states .h 

1.2 

drcsmdecode . pla 

10 . 3 

dr instantiate . h 

1 . 3 

droktoact .pla 

1 . 2 

droktopre .pla 

1 . 1 

droktoread . pla 

1 . 3 

droktowrite .pla 

3 . 13 

drout . V 

5 . 3 

droutde2Sel . pla 

1 . 4 

drpads . V 

1 . 2 

drpagecontrolstack . pla 

1 . 2 

drpagecsm .pla 

1.1 

drpagev.pla 

1 . 2 

drpmgen.pla 

1 . 1 

drpop .pla 

3 . 5 

drprbcsm.pla 

1 . 2 

drrc .pla 

1 . 3 

drreadcount . V 

1 . 2 

drreadcountsel .pla 

1 . 3 

drresetseq. pla 

1 . 2 

drrowscram . pla 

1 . 1 

drrp .pla 

1.5 

drsamplephase . pla 

1 . 3 

dr seqcheck . pla 

3 . 1 

dr spa c etna tch .Veqn 

6 . 2 

drtagqc .pla 

1 . 15 

drtester . V 

1 . 5 

drtester . h 

1 . 8 

drtop.V 

27 . 1 

drtop2 .V 

1.2 

drwritecount .pla 

1.3 

drwritedsel . pla 

20.10 

genpim.pl 

39.2 

genptab.pl 

20 . 8 

pimlib.pl 

1 . 1 

stripf lip 

Dir 

euterpe/verilog/bsrc/dr/conf ig 

1 . 1 

piaKeriie 

1.1 

dram . datasheet . explained 

1.1 

dram . datasheet . nec . 10 

1.1 

dram . datasheet . nec . 12 

1.1 

dram . system . datasheet 

1.1 

marg . c 
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1.1 system. datasheet .explained 

Dir euterpe/verilog/bsrc/dr/dram BOM 6.0 

1.4 Makefile 

1 . 1 README 

1.1 byl6_64m.ut 

1.1 by 81 6m. ut 

1.1 by8_64m.ut 

1 . 1 sdram . V 

1 . 2 sdram . h 

1.1 sdram . small .h 

1.1 sdram. ut 

1 . 1 spy . h 

1.3 tester. v 
1 . 1 tester . h 

Dir euterpe/verilog/bsrc/dr/dram/mit BOM 4 . 0 

1.3 Makefile 

1.1 mi t subi shi . sdram. model 

l.l op . v 

1.1 sdram. v 

Dir euterpe/verilog/bsrc/drio BOM 13 . 0 

3.4 . checkoutrc 
1.4 Makefile 

5.2 clean- request 

1.2 drio.V 

9.4 drio. power. tab. top 

1.1 genpim.pl 

1.1 pimlib.pl 

1.1 power .tab. local 

Dir euterpe/verilog/bsrc/es BOM 75.0 

4 5.1 . checkoutrc 

1.23 Makefile 

45.9 clean-request 
5.41 es.V 

5.41 es.pim 

65.7 es .power . tab . top 

40 . 10 es_xlu.V 
1.15 esaddbyt.V 

60.4 esaddbyta.V 
60.3 esalmsura.V 
60.3 esalmsumb.v 
1.27 esalu64.V 

1 . 10 escla. V 
1.84 escntrl.v 
1.29 esoraux.V 

I. 4 estop. V 

37 . 11 genpim.pl 
37 . 1 pimlib.pl 

13.6 power. tab. local 

Dir euterpe/verilog/bsrc/gf BOM 25.0 

II. 3 .checkoutrc 
1. 14 Makefile 

11.5 clean-request 
9 . 6 genpim , pi 

1.6 gf.V 

4.7 gf.pim 

19.5 gf . power . tab . top 

1.3 gfbit.pla 

1.11 gfbyt.V 
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1.1 gftop.V 

9.1 pimlib.pl 

Dir euterpe/verilog/bsrc/gt BOM 65.0 

39.3 . checkoutr c 

8.3 2gtlb.ut 

9.4 3gtltgtlb.ut 
1.25 Makefile 

41.5 clean-request 

26.6 genpim.pl 

14 . 3 genpipedat . pi 

24.4 genptab.pl 

7 . 15 gentst .pi 

2.20 gt.V 

54.5 gt .power . tab . top 
2 6.16 gt_control .pirn 

7.25 gt_driver.V 
9 . 4 gtdone.pla 

2 8.1 gtibwe.pla 
10.12 gtinstantiate . h 

7.4 gtrdy.pla 

7 .26 gtsnake.V 

7.5 gtsnakemuxctl .pla 

7 . 7 gtspmatchearly . Veqn 

7.21 gtspmatchlate . Veqn 

7 . 4 gtwe . Veqn 
26.8 pimlib.pl 

Dir euterpe/verilog/bsrc/hc BOM 74.0 

3 5.8 . checkoutr c 
1.26 Makefile 

4 0.5 clean- request 

34 . 4 genpimO .pi 
32.8 genpiml.pl 

12.5 gentst.pl 
1.39 hc.V 
3.13 hc.h 

8.5 hc.ut 

68.3 he 0 .power . tab . top 

73.1 hc0_control .pitn 

68.3 he 1 .power . tab . top 

73.1 hcl_control .pirn 

65.1 hc_brresp .pla 

6 . 2 hc_cmp6 . V 
27.17 hc_control .pirn 

8.8 hc_device.V 

3 . 16 hc_driver . V 

4 . 2 hc_error . Veqn 

12.3 hc_fifo8.V 

12 . 3 hc_f if o8ctr 1 . Veqn 
3 . 12 hc_ostate . pla 

3 . 9 hc_par se . Veqn 
3 . 11 hc_prbctrl .pla 
3 . 2 hc_rxcrc . Veqn 

3 . 8 hc_sdecode . Veqn 

3.11 hc_sid . Veqn 

3 . 4 hc_tagraatch . V 

3 . 2 hc__txcrc . Veqn 

13 . 1 hcinstantiate . h 

27 . 4 pimlib.pl 

17.6 power . tab. local 

Dir euterpe/verilog/bsrc/hz BOM 17.0 

4.2 . checkoutrc 

1.4 Makefile 
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4.4 clean-request 

4 . 4 genpim.pl 

1.10 hz.V 
9.4 hz.pim 

10.3 hz .power . tab. top 
1.1 hz . ut 

4.1 hz_control .pim 

1.3 hzmatch.V 

1.6 hztester.V 

1.1 hztester.h 

4.2 pimlib.pl 

4.1 power . tab . local 

Dir euterpe/verilog/bsrc/icc BOM 23.0 

15.1 . checkoutrc 

1.4 Makefile 

3.3 genpim.pl 
1.27 icc.V 

2.5 icc.h 

19.2 ice . power . tab . top 

16 . 4 icc_control . pim 

15.3 iccinhif e. Veqn 

1.8 iccxci6.Veqn 

1.9 iccxci7.Veqn 
3 . 5 pimlib.pl 

Dir euterpe/verilog/bsrc/ife BOM 44.0 

18.1 .checkoutrc 

4.2 1 . ut 

1.11 Makefile 

18.3 clean-request 

15.5 genpim.pl 
1.2 if.h 

1.7 ifbr.tst 
1.35 ife.V 

4 0.1 ife. power. tab. top 

15.9 if e_control.pim 

1.4 iffree.tst 
1.4 iffreeS.tst 

1.4 ifhold.tst 

1.8 ifpcselil.Veqn 
2 . 7 if rst . tst 

1.2 ifwntdi3 . Veqn 

1.10 ifwntdi4 . Veqn 
2 8.1 ifwntdie . Veqn 

15 . 2 pimlib.pl 

15.1 power . tab. local 

Dir euterpe/verilog/bsrc/io BOM 34.0 

9.5 . checkoutrc 
1.15 Makefile 

9.8 clean-request 

8 . 4 genpimO .pi 

8.5 genpiml.pl 

24.4 ioO .power .tab. top 

22.6 io0_control .pirn 
24.4 iol .power . tab. top 
22.4 iol control . pim 
31.1 io_buf _8 . V 

6.3 io_ififo.V 

6 . 1 io_iphase . Veqn 

6.1 io_ofifo.V 

6 . 1 io_ophase . Veqn 

6.2 io_scioff_6.V 
6.1 io_scioff_9.V 
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3.1 iocount.pla 

3 . 2 iodrive.V 
3 . 1 iof s . Veqn 
3.9 iorate.V 

4.7 pimlib.pl 

7.3 power . tab. local 

Dir euterpe/verilog/bsrc/iq BOM 51.0 

2 2.3 . checkout rc 

12.1 l.ut 
1.35 Makefile 
24.6 clean-request 

2 0.7 genpim.pl 
1.27 iq.V 

5 0.2 iq . power . tab . top 

20 . 14 iq_control .pirn 

2.6 iqbr.tst 
1.9 iqfree.tst 

1.8 iqfreeS.tst 
1.8 iqhold.tst 
1 . 9 iqholdS . tst 

1 . 1 iqholdq2 . Veqn 

1 . 1 iqholdq7 . Veqn 

1.4 i qho ldqq . Veqn 

3 . 1 iqpredq4 .Veqn 
3 . 1 iqpredq9 . Veqn 

9.3 iqrst.tst 
20.4 pimlib.pl 

20.2 power . tab . local 

Dir euterpe/verilog/bsrc/lt BOM 79.0 

56.1 . checkoutrc 

3.29 Makefile 

56 . 6 clean-request 

56.1 genpim.pl 

56.1 genptab.pl 
3.66 lt.V 

68 , 6 It .power . tab. top 

56 . 9 lt_control .pirn 

7.7 ltstldenbl.Veqn 
56 . 10 pimlib.pl 

Dir euterpe/verilog/bsrc/mc BOM 55.0 

17.3 .checkoutrc 
1.17 Makefile 

17.8 clean-request 

13.9 genpim.pl 
1.19 mc.V 

3 8.6 mc . control . obs 

4 8.1 mc . control .pirn 
4 8.1 mc .dataHigh.pim 
4 8.1 mc . dataLow.pim 

6.2 2 mc.pim 

3 7.5 mc . power . tab . top 

14.2 7 mc_xluc.V 
(14.26) 

28 . 2 mc_xlud.V 

1 . 6 mcacc8 .V 

1.4 mcaddbyt.V 

1.1 mcadf32.V 
1 . 11 mcalu64 . V 

1.2 mccla.V 
13 .2 pimlib.pl 

16.2 power. tab. local 
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Dir euterpe/verilog/bsrc/mg BOM 42.0 

14.3 lstr.ut 
1.30 Makefile 
1 . 1 dee . in 

1 . 1 dco . in 

1.3 rag . h 

8.21 ragrst.tst 

1.23 rslt.tst 

10.9 str.tst 

Dir euterpe/verilog/bsrc/mst BOM 31.0 

13.2 .checkoutrc 

I. 15 Makefile 
13.7 clean-request 

II. 5 genpim.pl 
20.1 rasacclS.V 
1.1 msadf32.V 
1.5 msbooth.V 
20.1 mscsaddl6a.V 
2 0.1 rascsaddl6b.V 
20.1 mscsaddl6e.v 

1.3 mshotc.V 

2 0.1 mshotca.V 
20.1 msinl6a.V 
20.1 msinl6b.V 
20.1 msrcdl6.V 
20.1 msrcdlSa.V 
20.1 msrcdlSb.V 
1.11 mst.V 

2.17 mst.pim 

23.5 mst. power. tab. top 

1.1 rastop.V 
11.1 piralib.pl 

Dir euterpe/verilog/bsrc/nb BOM 96.0 

4 6.5 . checkoutrc 

1 .40 Makefile 

1 . 3 README 

4 6.7 clean-request 

31.13 genpim.pl 

52.4 genptab.pl 

1.4 muxf f 17_1 . V 
1.4 muxffl7_4.V 

1.2 muxffl7_5.V 
1.62 nb.V 

31.10 nb.h 

82.5 nb . power . tab . top 
31.4 nb. toplevel .ut 

14.11 nb.ut 

3 8.33 nb_control .pirn 
8 8.5 nb_mid.pim 
88.4 nb_top.pim 

9.18 nbal6x64.tpl 
31.19 nbctrl.Veqn 
9.18 nbd3 2x64.tpl 
1.13 nbfq.V 

44.4 nbf qcount .pla 

1.3 nbfqprienc.pla 
1 . 5 nbf qslice . pla 

44.3 nbfulllp.pla 
90.1 nbgotone . V 

90.1 nbgotoneslice . Veqn 

12 . 2 nbholdof f . pla 
68.1 nbholdoff3.pla 
1.13 nbperiph.V 
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1.13 nbpq.V 

1.3 nbpqhelper .pla 

1 . 3 nbpqptrbitO .Veqn 

1.5 nbpqptrs lice. Veqn 

7 . 4 nbprbarb . Veqn 
7 . 2 nbprbcount . pi a 

1.5 nbrq.V 

1.3 nbrqptrbitO . Veqn 

1.3 nbrqptrslice.Veqn 

1.50 nbtester.V 

1 . 8 nbtester . h 

8 . 3 nbvd . pla 
15.5 nbwe . Veqn 

31.13 pimlib.pl 

Dir euterpe/verilog/bsrc/nb/rf BOM 5.0 

1 . 4 Makefile 
1.1 rf . ut 

1.4 rflrlw.V 

1.1 rflrlwl6wx64b.h 

1.1 rf Irlw32wx64b.h 

1.1 rftester.V 

1.1 rf tester. h 

Dir euterpe/verilog/bsrc/periph BOM 8.0 

1 . 6 Makefile 
1 . 1 README 

1.1 p.ut 

3 . 2 sptest .ut 

Dir euterpe/verilog/bsrc/rf BOM 3 . 0 

1.2 l.tst 

1 . 7 Makefile 

1.3 dor f spy 

1.2 drvchk.V 

1.6 rf_l.V 

1.5 rf_5.V 

1.3 rf_dec.Veqn 
1 . 2 run . V 

1.2 spy.V 

Dir euterpe/verilog/bsrc/rg BOM 97.0 

60.2 . checkoutrc 

14.1 lbr.ut 

14.2 le.ut 

14 . 3 lraul .ut 
1.47 Makefile 
60.5 clean- request 
19 . 11 genpira .pi 

82.1 genptab.pl 
19.22 pimlib.pl 

19.2 power . tab. local 

29.14 rg.V 
82.10 rg.pim 

7 9.5 rg. power . tab. top 

67.3 rg_control .pirn 
1.11 rgcr.V 

1.20 rgdp.V 

1 . 7 rgimm . V 
1.27 rgpc.V 

52 . 1 rgplrO .pla 

9 . 19 rgrst . tst 

1.15 rslt.tst 
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Dir euterpe/verilog/bsrc/rgxmit BOM 23.0 

1.4 . checkout rc 

1.3 Makefile 

8 . 4 clean- request 
1.2 genpim.pl 
1.1 pimlib.pl 

1.1 power . tab. local 

1 . 2 rgpcbrr 7 . Veqn 

1 . 1 rgwewk . Veqn 
1.15 rgxmit.V 

19.2 rgxmit .power . tab. top 

1 . 5 rgxmit_control . pirn 

Dir euterpe/verilog/bsrc/sr BOM 4 9.0 

24.5 . checkout rc 

1.19 Makefile 

26.5 clean- request 

16. 9 genpim.pl 

27 . 5 genptab.pl 

16.11 pimlib.pl 

2.26 sr.V 
(2.25) 

3.4 sr.h 

3 9.5 sr . power . tab . top 

1.2 sr_cla.Veqn 
16.19 sr_control .pirn 
(16.17) 

1 . 9 sr_dr iver . V 

3 . 3 sr_eventl6 . Veqn 

3 . 4 sr_eventreg . V 
16.4 sr_eventreg . pirn 

3 . 5 sr_evmaskl6 . V 
41.1 sr_hcevent.V 

1.3 sr_inc4.pla 

I . 3 sr_inc4a . pla 

2.4 sr_match.V 

II. 1 sr_mchold. Veqn 
3 . 3 sr_radecode . pla 
1.3 sr_timer.V 
16.2 sr „ fc imer . pirn 

3 . 2 sr_wadecode . pla 

Dir euterpe/verilog/bsrc/tst BOM 77.0 

13.2 le.ut 

13.3 libr.ut 

13.2 liss.ut 

13.3 11. ut 
13.2 lpc.ut 
13.1 lq.ut 
13.1 lstr.ut 
1.23 Makefile 
1.9 br.tst 
1.60 drvchk.V 
70.1 ic.tst 
6.31 job.tst 
1.11 rslt.tst 
3 3.12 rsrvd.tst 
1.23 rst.tst 
1.15 spy.V 
3.7 tstgen 

6.27 tstrst.tst 
3 . 1 vervars 

3 . 4 vew 

3 . 1 vlwire 
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Dir 


euterpe/verilog/bsrc/uu 


BOM 125,0 


79.2 

. checkoutrc 

25. 1 

1 .ut 

25 . 1 

le .ut 

25.2 

limm.ut 

25.2 

limmpc . ut 

25 . 1 

liss .ut 

25 . 1 

lnb.ut 

25 . 1 

Ipc .ut 

1.67 

Makefile 

2 . 13 

br . tst 

78 . 7 

clean- request 

68.4 

genpim .pi 

68 . 1 

pimlib .pi 

81.1 

power . tab . local 

123 .2 

uu- local .obs 

1 . 131 

uu. V 

1 .32 

uu.h 

119.2 

uu . power . tab . top 

68 .16 

uu_control .pirn 

1.20 

uubruv . tdcd 

1.13 

uubruw . Veqn 

1.19 

uubypltncyuv . tdcd 

1.4 

uuchkdstr3 .Veqn 

1 .10 

uuchkdstuw . Veqn 

112 . 1 

uucmp2rn. V 

1 . 9 

uudstselut . tdcd 

1.9 

uuf ree . tst 

1. 15 

uuhold. tst 

1 . 17 

uuholduu . Veqn 

1 . 19 

uuimmpc . tst 

1 . 30 

uuimmpcut .tdcd 

24 . 11 

uuimmus . tdcd 

1. 12 

uuisdstuv .tdcd 

1.1 

uuisdstuvsplit 

1.21 

uuissrcur . tdcd 

28 . 9 

uu j ob 1 s tux . Ve qn 

63 . 8 

uuraerauv .tdcd 

8 . 13 

uuraic . tst 

8 . 11 

uuraicut . tdcd 

9 . 7 

uumicuu . tdcd 

112 . 3 

uuovrlyregreg . V 

36 . 12 

uuprblraf rz . Veqn 

108 . 3 

uuprblmrO .Veqn 

108 . 3 

uuprblmrlO .Veqn 

50 . 5 

uuprblmrll . Veqn 

50 . 5 

uuprblmrl2 .Veqn 

60 . 3 

uuprblrarl3 .Veqn 

50 . 7 

uuprblmr5 .Veqn 

50 . 1 

uuprblrar6 .Veqn 

107 . 3 

uuprblrar7 .Veqn 

50 . 7 

uuprblmr8 .Veqn 

61 . 6 

uuprblmr 9 . Veqn 

32 . 7 

uuprblmup . Veqn 

50 . 9 

uuprblmwm . Veqn 

14 .30 

uupreemuq . Veqn 

1.2 

uupsi . pla 

8 . 2 

uurbuu . Veqn 

15 . 10 

uursltbypcuu . Veqn 

1 . 18 

uursltbypuu . Veqn 

28 . 8 

uursrvd. tdcd 

15 . 21 

uurst . tst 

53 .1 

uurstuq.pla 

76.1 

uurup t r 1 2 . Veqn 

84 . 5 

uusteput .pla 

84.3 

uustepuu.pla 

1.13 

uuthruus . tdcd 
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1 . 9 uuthruut . Veqn 

1 . 2 uuwew j . Veqn 

Dir euterpe/verilog/bsrc/xlu BOM 47.0 

28.2 . checkout rc 

1.44 Makefile 

8 . 1 TODO 

25.1 cl.srf 

25.1 c2.srf 

26.1 c3.srf 

36.1 clean- request 

25.1 cs2.srf 

25.1 cs3.srf 

23.2 db_7a.srf 
21.5 dc_8a.srf 
8.20 genpim.pl 
22 . 4 misc2 . srf 

22 . 3 misc3 . srf 

8.19 piralib.pl 

3 5.1 power . tab. local 

21.4 q_9a_7.srf 
19 . 14 route .pi 

33.7 xl23.pim 

40.1 xl26.pim 

33.2 x456.pim 
25.1 xbus.srf 

24.8 xlu.V 

14.4 xlu.mpc 
35.1 xlu.nets 
33 . 1 xlu.nof lip 

17 . 5 xlu. rcf 
33 . 7 xlu4 . obs 

39.1 xlu6 . obs 

41.2 xlu_add4.V 
1.16 xlu_ctrldata . c 
1 . 2 xlu_la_r2 . c 

18 . 2 xlu_sr . c 
28.1 xlu_sr_c3 .dir 

28.3 xlu__sr_r2 . dir 
28.1 xlu_sr_r 3 . dir 
6.2 xlu_tr_sl.c 

2 8.1 xlu_tr_sl . dir 

6 . 2 xlu_tr_s2 . c 

28.1 xlu_tr_s2 .dir 

6 . 2 xlu_tr_s3 . c 

26.1 z3.srf 

25.1 zs3.srf 

Dir euterpe/verilog/bsrc/yy BOM 21.0 

1.14 Makefile 

1.2 dob2dascii 

2.2 dotestassign 

1.20 tas.pl 
2.1 test.V 
1.1 yy.h 

1.5 yyunasm.V 

1 . 5 yyunasmmnesel . tdcd 

1 . 5 yyunasmmusel . tdcd 


===> running euterpe/verilog/bsrc/ . checkoutrc (Thu Jan 5 14:30:46 PST 
1995) <=== 

pager lisar Id: BOM,v 199.0 1995/01/05 13:35:40 LT billz Exp page queued starting paged 
for i in at au cc cdio ce eg cj ck cp ctioi ctiod dr drio es gf gt he hz ice ife io iq It 
mst rac nb rg rgxmit sr uu xlu; do \ 

graake -C ${i} vfiles | | exit; \ 

done 

gmaketl]: Entering directory 
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* /N/auspex/root/slO /chip/euterpe/verilog/bsrc/at 1 
gmake [1] : "vf iles ' is up to date, 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/at 1 
gmake [1] : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/au' 
graake[l] : "vfiles* is up to date. 
gmake[lj : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/au 1 
gmake [1] : Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc ' 
gmake [1] : Entering directory 

** /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cdio ' 
gmake [1]: "vfiles' is up to date, 
gmake [1] : Leaving directory 

""/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cdio ' 
gmake [1]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/ce ' 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f . h cerberus.V | /lib/cpp -P -C -B | 
sed -e '/ A $/d'> cerberus . v. tmp mv cerberus . v. trap cerberus.v cat 

/n/auspex/slO/chip/euterpe/proteus/verilog/dif f .h cemaster.V | /lib/cpp -P -C -B | sed -e 
'/ A $/d'> ceraaster . v. tmp cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f .h ce_cms2ecl.V 
j /lib/cpp -P -C -B | sed -e </*$/d'> ce_cms2ecl . v . tmp cat 

/n/auspex/slO/chip/euterpe/proteus/verilog/dif f .h ce_mck.V j /lib/cpp -P -C -B | sed -e ' / 
A $/d'> ce_mck.v.tmp mv ce_cms2ecl . v. tmp ce_cms2ecl.v mv cemaster . v. tmp cemaster.v mv 
ce_mck.v.tmp cemck.v echo cerberus.v ceslave.v cecore.v ceregcore.v cerbctrlreg . v 
cerbtempreg . v cerbskewreg. v cedpreg.v ceclockbiasbuf . v ceregbuf.v cerbnobreg.v cetstmux.v 
cemaster.v ce_flash.v ce_cms2ecl.v ce_kybd,v ce_kybdcntr . v ce_seg7.v ce_mck.v [ tr ' 1 
1 \012 1 > vf iles 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ ce ' 
gmake [1] : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/cg 1 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dxlib/xlib.conf ig 
/n/auspex/slO/chip/euterpe/proteus/verilog/dclib/clib . conf ig 

/n/auspex/slO/chip/euterpe/proteus/verilog/delib/elib. conf ig > v2e.config cp v2e.config 
clockbias . conf ig echo 'lib clockbias = cgclockbias; omit contents clockbias; ' >> 
clockbias . conf ig CHIPROOT^/n/auspex/ slO/chip/euterpe 

/n/auspex/sl0/chip/euterpe/tools/bin/v2e -host gamorra cgclockbias .v -c clockbias . conf ig 
-o cgclockbias. v2e -y /n/auspex/slO/chip/euterpe/proteus/verilog/mlib +libext+.v -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dxlib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dclib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/delib 
V2E 1.0a Jan 5, 1995 14:31:12 

* Copyright Cadence Design Systems Inc. 1990. * 

* All Rights Reserved. Licensed Software. * 
+ Confidential and proprietary information which is the * 

* property of Cadence Design Systems Inc. * 
Compiling source file "cgclockbias .v" 

Scanning library directory 

"/n/auspex/slO/chip/euterpe/proteus/verilog/mlib" 
Scanning library directory 

"/n/auspex/slO/chip/euterpe/proteus/verilog/dxlib" 
Scanning library directory 

" /n/auspex/slO/chip/euterpe/proteus/verilog/dclib" 
Warning! library directory 

M /n/auspex/slO/chip/euterpe/proteus/verilog/mlib n was specified but not needed. 
Warning! library directory 

" /n/auspex/slO/chip/euterpe/proteus/verilog/dxlib" was specified but not needed. 
Warning! library directory 

"/n/auspex/slO/chip/euterpe/proteus/verilog/delib" was specified but not needed. 

Highest level modules: 

cgclockbias 

Reading configuration file clockbias . conf ig .... 
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Processing configuration file .... 
Translating Verilog source .... 
Writing output to cgclockbias . v2e .... 
0 warnings 0 errors 

End of V2E 1.0a Jan 5, 1995 14:31:26 
echo cgclockbias. v | tr ' ' '\012» > vfiles 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cg ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cj 1 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cj ■ 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ck ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ck' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cp ' 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f ,h cp.V j /lib/cpp -P -C -B | sed -e 
'/ A $/d'> cp.v.tmp mv cp.v.tmp cp.v echo cp.v | tr 1 1 1 \012 1 > vfiles 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cp ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctioi 1 
gmake [1] : "vfiles' is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctioi ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod ' 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/dr ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/dr ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/drio 1 
gmake [1] : "vfiles* is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/ euterpe/verilog/bsrc/drio ' 
gmake [13 : Entering directory 

"/N/auspex/root/ slO/chip/euterpe/verilog/bsrc/es ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/es ' 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/gf 1 
gmake [1]: "vfiles" is up to date, 
gmake [1]: Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/gf 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/gt ' 
gmake [1]: "vfiles' is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/ euterpe/verilog/bsrc/gt ' 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 
gmake [1]: "vfiles' is up to date, 
gmake [1]; Leaving directory 

" /N/auspex/root/slO/chip/ euterpe/verilog/bsrc/hc ' 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hz ' 
gmake [1] : "vfiles' is up to date, 
gmake [1] : Leaving directory 
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" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hz 1 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/icc ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/icc ' 
gmake [1] : Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/if e ' 
gmake [1]: "vfiles 1 is up to date, 
gmake [1]: Leaving directory 

- /N/auspex/root/slO/chip/euterpe/verilog/bsrc/if e ' 
gmake [1]: Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/ io 1 
gmake [1]: "vfiles 1 is up to date, 
gmake [1 J: Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/io 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/iq 1 
gmake [1] : "vfiles' is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/iq 1 
gmake [1] : Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/lt ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/lt ' 
gmake [1] : Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/mst ' 
gmake[13: "vfiles' is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/mst ' 
gmake [1]: Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/mc ' 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f . h mc_xluc.V | /lib/cpp -P -C -B | sed 
~e • / x $/d'> mc_xluc . v . tmp mv mc_xluc . v . tmp mc_xluc.v echo mc_xlud.v mc_xluc.v mc.v 
mcalu64.v mcaddbyt.v mccla.v mcacc8.v mcadf32.v j tr ' ' ' \012' > vfiles 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/mc » 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb' 
gmake [1] : "vfiles' is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb 1 
gmake [1] ; Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/rg • 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/rg ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/rgxmit " 
gmake [13 : "vfiles 1 is up to date, 
gmake [13 : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/rgxmit 1 
gmake [1] ; Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/sr 1 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f , h sr.V | /lib/cpp -P -C -B | sed -e 
'/^$/d'> sr.v. tmp mv sr. v. tmp sr.v echo sr.v sr_timer.v sr_match.v sr_eventreg . v 
sr_evmaskl6 . v sr_hcevent.v sr_inc4.v sr_inc4a.v sr_radecode . v sr_wadecode.v sr_cla.v 
sr_eventl6.v sr_mchold.v | tr 1 ' 1 \012 ' > vfiles 
gmake [13 : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/sr ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/uu 1 
gmake [1] : "vfiles' is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/uu' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/xlu 1 
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gmake[l] : "vfiles* is up to date, 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/xlu' 
rm -f vfiles 

for i in at au cc cdio ce eg cj ck cp ctioi ctiod dr drio es gf gt he hz ice ife io iq It 
mst rac nb rg rgxmit sr uu xlu; do \ 

sed -e ' /*$/<*' < ${i}/vfiles | sed -e "s ! " ! $ {i } / ! " » vfiles; \ done 
[finished at Thu Jan 5 14:32:22 PST 1995 exit status 0] 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Thursday, January 05, 1995 5:08 PM 
'Mark Semmelmeyer' 
'euterpe@tallis'; 'karzes@tallis' 
Re: gextract 


Mark Semmelmeyer wrote {on Thu Jan 5) : 

> From abbott@tallis Thu Jan 5 11:08:01 1995 

If EAddl is latency 1, then EShLI is latency 2, and a 3 issue 
step op like gextractl28 in hardware would be latency 4. 
Then your only penalty is code space. 

Whoops, I overlooked that. Thanks. 


I am assuming that the compiler or some tool will stuff 
something useful into the issue slot otherwise wasted. . . 

Yes, the compiler is quite good at it. 

Also, Scott points out that gmshr (grotr ( . . . ) ) does the old, 7-bit shift count gextractl28, 
which I'd overlooked. The old gextractl28 is good for aligning hexlets, which is what I 
was thinking of. The new functionality of the implemented gextractl28 is good for lookup 
in 256 bit tables, so that's not replaced. (However, with a 3 issue slot gextractl28, 
we ' d probably use loads - - did for DES at any rate . ) 


- Curtis 
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From: geert (Geert Rosseel) 

Sent: Friday, January 06, 1995 8:59 AM 

To: 'billz'; 'brianl'; 'dickson'; 'hopper'; 'mws'; 'tbr'; 'woody' 

Subject: nb 

nb BOM 96.0 has FATAL timing errors after pass3 and does not iterate 
The output is in : /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/nb 
Geert 


Exhibit CIO 


Page 68 of 356 


From: michael (Chris Michael) 

Sent: Friday, January 06, 1995 12:22 PM 

To: 'euterpe' 

Subject: Huns models 

Design Folk, 

The old nuns models have been placed in a mobi-like format. 
The path to the HSPICE model library is: 

.lib 7u/chip/technology/huns/hspice/models.lib' huns_60 


Some notes on the models: 

- There are four devices in the models file: NMOS, PMOS, low-Vt NMOS, 
and NPN. The NMOS, PMOS, and BJT models should function similar to 
the mobi models (exceptions to this statement will be noted below). 

The subcircuit name for the low-Vt NMOS is 'NWS' (Vt is -0. 14V). 

- Library does not include diode, resistor, capacitor, or wire models. 
Just the four transistors. 

- No corner models - Pspeed, Nspeed, and Bspeed will have no effect. 

- Temperature models for the NMOS and PMOS will be accurate only at 
25 C and 1 10C. Models aren't reliable at any other temperatures. The 
low-Vt NMOS model works at 25C only. 

- MOS models are Level 3. They exhibit typical Level 3 model problems, 
including kinks at the transition between linear and saturation regions 
and poor sub-Vt characteristics. These models probably do not scale 
well with gate length - 1 would guess that they're only accurate for 
minimum gate lengths (0.6u for NMOS and PMOS, 0,7u for low-Vt NMOS). 
There is some attempt at modeling narrow width effects. 

- These are old models (at least 2.5 years old), and will undoubtedly 

be revised once we get more information from the huns. Hopefully, we'll 
have more complete models at that time. 


Chris 
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From: 


craig 

Friday, January 06, 1995 1:07 PM 
'abbott@taHis'; 'karzes@tallis' 
'euterpe@tallis'; 'software^tallis' 
Re: gextract 


Sent: 

To: 

Cc: 


Subject: 


The above discussion seems to reinforce previously asserted claims that; 

1) gextract can be microcoded in two pipeline flows. 

2) a bypass from second- stage output to second- stage input can 
improve performance for relatively low implementation cost. 

Craig 
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Sent: 

To: 

Cc: 


Subject: 


From: 


wampler (Kurt Wampler) 

Friday, January 06, 1995 5:53 PM 

'geeif 

'hopper'; 'tor'; 'torn'; 'vo' 
Congestion analysis 


Hello, Geert, 

I'm still getting Euterpe to route to about 99.2% complete before it runs out of resource. 
I've played around quite a bit with route order, and come to the conclusion that there are 
some congestion hot spots that just don't have enough tracks, no matter what I do with the 
route order, 

I've put some experimental congestion estimation code into the net_select gears program 
which allows the user to sweep a cut -line across a particular bounded region of the chip 
at an arbitrary stepping interval and report the number of nets that cross the cut -line at 
each step. Using this approach, I've analyzed the datapath and the two narrow SOFA 
"pillars" at the north end of the chip and have some congestion data to report. I have a 
plot showing regions where the number of required connections exceeds the available 
routing tracks ; the worst numbers are between 1 . 5 and 2x the number of available tracks . 
We clearly have some work to do in these regions to alleviate the routing congestion. 

I understand you're out sick today, but as soon as you make it back in, I'd like to show 
you the plot and discuss possible solutions for these problem areas. 

The latest routing attempts are in /n/rhodan/s2 /wampler/ euroute if you want to examine the 
remaining unroutes. I have a plot of the unroutes also. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 
Friday, January 06, 1995 6:01 PM 
'Geert Rosseel' 
Re: nb 


Geert Rosseel writes: 


nb BOM 96.0 has FATAL timing errors after pass3 and does not iterate 

The output is in : 
/n/auspex/s4l/euterpe- snapshot /euterpe/verilog/bsrc/nb 

I talked with Billz about this. In trying to fix the global timing error he introduced a 
local timing error. I'm trying an experiment: I re-mincut NB . I'll see if that gives 
something that I think might time better at the top level . 


-mark 
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From: Tom Karzes [karzes@MicroUnity.com] 

Sent: Friday, January 06, 1995 6:34 PM 

To: 'abbott@MicroUnity.com'; 'dickson@MicroUnity.com' 

Cc: 'software@MicroUnity.com'; 'euterpe@MicroUnity.com' 

Subject: gextract 


Ok, I've had a chance to look at this, and here are my observations. 
The 12 8 -bit gextract equivalent given was: 

> To do gextract 12 8 (hi, lo, sh) : 

> gmshrl2 8 (grotrl28 (hi, sh) , lo, sh) ; 

As has been pointed out, this only works if the shift amount is < 128. 

It was also pointed out that the latency of 4 is just as good as the current hardware 

implementation, which I believe is also 4, with the use of 3 issue slots rather than 2. 

A little history on this would probably be helpful. The original plan for using multiple 
XLU passes for gextract. 128 called for an initial pass which would generate a mux mask, 
followed by a second pass which performed the appropriate shift or rotate on the muxed 
data. This would have used 2 issue slots and would have had a latency of 3. Since it 
seemed unlikely that we would improve on this, we didn't give it much more thought and it 
stood until it came time to implement it. When it was actually implemented, an 
unpublicized change was made which changed this to 3 issue slots with a latency of 4 . 

This scheme used the following alogrithm: 

mask = sh[7] ? 0 

: gshl.128 (Oxfffffff ffffffff fffffffffffffffff , sh[6:0]) 

src = gmux(mask, lo, hi) 

result - sh[7] ? signed ? gshr . 128 (src, sh[6:0]) 
: gushr . 128 (src, sh[6:0]) 
: grotr . 128 (src, sh[6:0]) 

The extra work here is computing the mask and using it to mux the hi and lo operands to 
form the final src operand to the XLU. In the current implementation this step occupies 2 
issue slots and adds 2 cycles to the latency, as opposed to the 1 issue slot and 1 
additional cycle that was originally planned. 

The method Curtis proposes would eliminate the mask and mux completely, and would instead 
take advantage of the xbus to supply the XLU with a total of 

256 operand bits. However, the data on the xbus would first have to be rotated by the 
XLU. When modified to handle the additional high bit of shift amount, the algorithm would 
be: 

merge = grotr . 12 8 (hi, sh[6:0]) 

result = sh[7] ? signed ? gshr. 128 (hi, sh[6:0]) 
: gushr. 128 (hi, sh[6:0]) 
: gmshr .128 (merge, lo, sh[6:0]) 

The biggest question here is how easy is it to put the result of the first XLU pass onto 
the xbus for the second, final pass? Note that it has to be muxed in, and if sh[7] is 1 
then it would be suppressed and 0 would be placed on the xbus instead (which is needed for 
zero fill for unsigned right shift) . In addition, the primary input to the final XLU pass 
would either be hi or lo, again depending on sh[7] . 

So the question is, would supporting the path from the XLU output to the xbus require 
adding more gates than would be freed by removing the current logic for generating and 
using the mux mask? Perhaps Rich can answer this for us . 
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The 64 -bit gextract equivalent given was: 

> To do gextract64 (hi, lo, sh) : 

> grashr64 (grotr64 (hi, sh) , lo, sh) ; 

This isn't correct. Remember, for group sizes smaller than 128, a gextract is identical 
to two independent gcompresses. In particular, the hi and lo operand bits never mix; the 
high 64 bits of the result come from hi and the low 64 bits of the result come from lo. 
The hardware implements this as a 2 -issue, 3 -latency operation, which is exactly what you 
would get if you did this in software (the two gcompresses are independent) . 

The version shown above has a latency of 4 (since a sequential dependency has been 
introduced), but more importantly it simply isn't correct. To see this, let's construct a 
specific example: 

hi : aaaaaaaaaaaabbbb , ccccccccccccdddd 

lo: eeeeeeeeeeeef f f f , gggggggggggghhhh 

sh: 16 

r: bbbbcccccccccccc, f f f f gggggggggggg 

The result of gextract . 64 (hi, lo, sh) should be r, which is exactly what you'd get by 
performing a gcompress.64 on hi and a gcompress.64 on lo. However, if you used the 
translation shown above, you'd get: 

grotr: bbbbaaaaaaaaaaaa, ddddcccccccccccc 
gmshr: bbbbeeeeeeeeeeee, ddddgggggggggggg 

which is clearly incorrect. There may be situations where you'd want this, but is isn't a 
gextract. 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Friday, January 06, 1995 6:49 PM 
'geeiKgrhea' 
pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/sr BOM 50.0 initiated by woody completed @ Fri Jan 6 16:48:18 
PST 1995 with exit status 0.. chip 

lock read: File exists 
all ports busy 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Friday, January 06, 1995 7:16 PM 
Tom Karzes' 

'dickson@MjcroUnity.com'; 'euterpe@MicroUnity.com' 
gextract 


Just a couple of comments on the comments. It was/is not my intention to remotely suggest 
that we change direction on the current Euterpe implementation. The purpose of the wide 
broadcast was to alert people to the fact that the somewhat unpleasant 3 issue- slot 
gextractl28 could be replaced, in the purposes we're using it for, with a 2 instruction 
pair that uses 2 issue- slots. The fact that gextractl28 has become somewhat superfluous 
in this implementation seems to me irrelevant. If we'd noticed earlier, we might have 
left it out, but it certainly doesn't make sense to go back and rip things up now. 

Second, Tom points out that my code for gextractN N<128 doesn't work, and his example 
makes clear that it would if lo64(hi) and hi64(lo) are swapped (in the 64-bit case -- more 
generally, a transpose is involved). My apologies. I thought I'd run that case in my 
test program, but I obviously hadn't. 


- Curtis 
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From: age (Alan Corry) 

Sent: Friday, January 06, 1 995 7: 1 7 PM 

To: 'Jean-Yves Michel' 

Cc: 'graham (Graham Y. Mostyn)'; 'tony (Tony Stelliga)'; 'jt (John Tang)'; 'hessam (Hessam 

Mohajeri)'; 'pandora' 
Subject: RE: Euterpe housing containing Calliope 


> > From graham Wed Dec 21 13:31:47 1994 

> > Date: Wed, 21 Dec 1994 13:31:43 -0800 

> > From: graham (Graham Y. Mostyn) 

> > To: graham@charybdis, tony@charybdis 

> > Subject: RE: Euterpe housing containing Calliope 

> > Cc : yves, hessam, jt 

> > Content -Length: 807 

> > 

> > Re: the "first-out" minimal interface Calliope: 

> > I suggest that we might consider various combinations that could 

> > have market appeal; these are intended to fit in the Euterpe brick 

> > size, and be low risk (other than d) . 

> > 

> > (a) I interpreted your email to suggest just a Calliope with a 

> > generic digital port that supports various wireline options (and 

> > perhaps other functions) . We would need to consider how the 

> > wireline electronics might be packaged; perhaps a set of additional 

> > same- size bricks that also fit in the rack, one for 3xISDN, one for 

> > Tl etc.?? 
> 

> That does not make too much sense: instead of designing 2 different 
bricks 

> (1. calliope + ISDN, 2. calliope + Tl) , we will be designing 3 bricks 

> (1. calliope, 2. ISDN, 3. Tl) with all the extra costs : mechanical, 

> power supply, board, connector . . . 
> 

> There are some limits to modularity. Each time we add a level of 

> modularity, we add in development cost, production cost and very often 

> we get a performance hit . 

> 

> > (b) Audio and NTSC video only. 

> > 

> > (c) Audio and RGB (metal change required for monitor quality) 
> 

> I don't think calliope can sustain any high quality RGB . What about 

> EGA 
or CGA? 

I believe this was discussed at the initial pandora meetings but not disseminated more 
widely. While it is certainly feasible to make a metal mask change to calliope to allow 
the current design to provide RGB video at up to a pixel rate of 108Mhz it was deemed 
unacceptable because of the enormous load it places on euterpe to drive a high- res display 
(not to mention the internal ring bandwidth that would be hogged by such a device) . Other 
suggestions which came up at the time included modifying mnemosyne to allow the dram 
interface to support video drams and thereby implement a framestore (eventually the 
conclusion was to implement the PCI controller mode in a mnemo chip) . 

Maybe craig and curtis should comment so we can at least document the thread that 
originally discussed this. I don't doubt that we will have to face the question of an RGB 
solution other than PCI in some future products. 
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From: Tom Karzes [karzes@MicroUriity.com] 

Sent: Friday, January 06, 1995 7:46 PM 

To: 'abbott@MicroUnity.com' 

Cc: 'dickson@MicroUnity.com'; 'euterpe@MicroUnity.com' 

Subject: gextract 


> Just a couple of comments on the comments. It was/is not my intention 

> to remotely suggest that we change direction on the current Euterpe 

> implementation. The purpose of the wide broadcast was to alert people 

> to the fact that the somewhat unpleasant 3 issue- slot gextractl28 

> could be replaced, in the purposes we're using it for, with a 2 

> instruction pair that uses 2 issue-slots. The fact that gextractl28 

> has become somewhat superfluous in this implementation seems to me 

> irrelevant. If we'd noticed earlier, we might have left it out, but 

> it certainly doesn't make sense to go back and rip things up now. 

Still, I think there's a lesson here. A 2- issue, 3 -latency gextract . 128 , which was 
originally proposed as a substitute for a 1- issue, 2 -latency version, would have been very 
useful. At the time it was discussed, it was claimed that it could be done with minimal 
hardware by using the XLU to generate a mux mask, and this seemed to satisfy everyone. 

When it came time to actually implement it, it was found that the 2 -issue, 3 -latency 
version that was originally planned would have taken too much additional hardware. At 
this point, those affected by it should have been notified, and we could have reexamined 
the problem. If this had been done, it is possible that someone would have suggested an 
alternative which 

*could* be implemented as a 2 -issue, 3 -latency instruction. The suggestion Curtis made 
may in fact have worked. Instead, the less desirable 3 -issue, 4 -latency version was 
implemented, still using the mask/mux approach, and nobody was notified of the problem or 
the change until after it was done . 
This was bad for 2 reasons: 

1. It eliminated the chance of finding a better way to do it because 
nobody was looking for it. Of course, there's no guarantee that 
a better method would have been found, but at least we could have 
opened the door for it. 

2 . People continued to write code and make timing estimates based on 
the more optimistic version because they weren't aware of the change. 
If we had been seriously depending on the 2 -issue, 3 -latency version 
in some critical loop, we might have overlooked a serious performance 
problem until it was too late to do anything about it. 

Sigh. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 
Friday, January 06, 1995 9:16 PM 
Tom Karzes' 

'abbott@MicroUnity.com'; 'dickson@MicroUnity.com'; 'euterpe@MicroUnity.com'; 

'software@MjcroUnity.com' 

gextract 


Tom Karzes wrote (on Fri Jan 6) : 


A little history on this would probably be helpful. The original 
plan for using multiple XLU passes for gextract. 128 called for an 
initial pass which would generate a mux mask, followed by a second 
pass which performed the appropriate shift or rotate on the muxed 
data. This would have used 2 issue slots and would have had a 
latency of 3 . Since it seemed unlikely that we would improve on 
this, we didn't give it much more thought and it stood until it 
came time to implement it . When it was actually implemented/ an 
unpublicized change was made which changed this to 3 issue slots 
with a latency of 4 . 

It may not have been explicitly documented in meeting notes, but it was discussed in two 
separate euterpe micro-architecture meetings and on both occasions I thought I made it 
clear we would not be implementing the required additional bypass because we were 
deparately looking for things to take out of the data path not things to add. 

Since then we have removed funtionality (priomarily the 4bit arithmetic ops) . We changed 
our leaf cell family, clocking methodology and lowered the cycle time to gain 15% area, 
turned up our default power setting again to save area, and finally have done heroic 
things to get the utilization up to the high 90s % range. As a result it does finally fit 
and we have so far got it 99.2% routed with very few remaining timing violations. 

I stand by that decision not to add the extra stuff in the datapath. 


Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


Tom Karzes [karzes@MicroUnity.com] 
Friday, January 06, 1995 9:50 PM 
1br@MicroUnity.com' 

'abbott@M icroUnity.com'; 'dickson@MicroUnity.com'; 'euterpe@MicroUnity.com'; 

'software@MicroUnity.com' 

gextract 


> It may not have been explicitly documented in meeting notes, but it 

> was discussed in two separate euterpe micro-architecture meetings and 

> on both occasions I thought I made it clear we would not be 

> implementing the required additional bypass because we were deparately 

> looking for things to take out of the data path not things to add. 

I certainly understand the need we had to reduce the amount of logic in the data path, and 
I'm not disagreeing with it. I'm simply making the following points: 

1. I was unaware of this change at the time it was made. 

2. I believe Curtis, and most of the other people in software, were 
unaware of this change as well. 

3. I don't recall seeing any mail to euterpe, or any other mailing list 
that I'm on, which mentioned this change (perhaps I missed it, but if 
so then I wasn't the only one) . 

4. It's not clear to me that the idea Curtis suggested wouldn't result 
in fewer gates, in addition to reducing the number of issue slots 
and the latency. It would require the ability to mux the XLU result 
into the xbus . However, this is *not* the same as the additonal 
bypass that was discussed for chaining XLU operations, which would 
have to feed into the primary XLU input, and would also have a 
significant impact on the bypass logic . The control for the gextract 
change would be much simpler than this. Furthermore, there are already 
muxes in the xbus path (or at least the ability to conditionally zero 
it), so it may be just a question of whether they're in a convenient 
point in the pipeline (or could be moved to a convenient point) , or 
whether a significant amount of staging would have to be added to make 
it work. It may turn out that this solution is too expensive to 
consider, but then again it may not, and in fact it might even save 
gates. I simply don't know. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 07, 1995 7:09 PM 

Tom Karzes' 

'abbott@MicroUnity.com'; Vjickson@MicroUnity.com'; 'euterpe'; 'software'; 'lisar 1 
gextract 


Tom Karzes wrote (on Fri Jan 6) : 

> It may not have been explicitly documented in meeting notes, but it 

> was discussed in two separate euterpe micro- architecture meetings and 

> on both occasions I thought I made it clear we would not be 

> implementing the required additional bypass because we were deparately 

> looking for things to take out of the data path not things to add. 

I certainly understand the need we had to reduce the amount of logic in 
the data path, and I'm not disagreeing with it. I'm simply making the 
following points: 


1. I was unaware of this change at the time it was made. 

2. I believe Curtis, and most of the other people in software, were 
unaware of this change as well. 

3. I don't recall seeing any mail to euterpe, or any other mailing list 
that I'm on, which mentioned this change (perhaps I missed it, but if 
so then I wasn't the only one) . 


It was not in any meeting notes I posed, I checked. However, I'm sure curtis was present 
at the meeting, and I thought you had been there when any significant XLU related issues 
were discussed. Perhaps the discrepancy came in because the software side assumed such a 
bypass would be added as a result of just discussing it, when in fact the hardware side 
had yet to asses the cost. I agree we did not do a good job of following up with the 
result . 

What does the simulator implement. I know lisar has discovered many significant 
discrepeancies by comparincycle counts on the hardware with those on the simulator and I 
would have expected one this significant to have shown up there. 


4. It's not clear to me that the idea Curtis suggested wouldn't result 
in fewer gates, in addition to reducing the number of issue slots 
and the latency. It would require the ability to mux the XLU result 
into the xbus. However, this is *not* the same as the additonal 
bypass that was discussed for chaining XLU operations, which would 
have to feed into the primary XLU input, and would also have a 
significant impact on the bypass logic. The control for the gextract 
change would be much simpler than this. Furthermore, there are already 
muxes in the xbus path (or at least the ability to conditionally zero 
it) , so it may be just a question of whether they're in a convenient 
point in the pipeline (or could be moved to a convenient point) , or 
whether a significant amount of staging would have to be added to make 
it work. It may turn out that this solution is too expensive to 
consider, but then again it may not, and in fact it might even save 
gates. I simply don't know. 


I agree it's possible curtis' s suggestion may save gates, and it's certainly the case that 
this special case is much cheaper than the 

general bypass that was originally proposed. However, as 

we are now more than 6 months behind schedule on getting euterpe taped out I am unwilling 
to consider changes as significant as this at this stage. Clearly it's something we would 
revisit in a future major revision. 


Tim 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Sunday, January 08, 1995 3:02 AM 

'geert (Geert Rosseel)' 

nb 


Geert , 


I have a much nicer (right edge) placement of NB in 
-hopper /chip/euterpe/verilog/bsrc/nb/gards 
The right edge is 164 0. 

I will presently trash this result when I move the arrays left by 60 units. 

Do you regard the 560 x-value left edge for the arrays as stable and final? 
Should I wait? 


-mark 
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From: torn (Tom Laidig) 

Sent: Sunday, January 08, 1995 2:47 PM 

To: 'wampler (Kurt Wampler)' 

Cc: 'torn (Thomas Laidig)'; 'ong (Warren R. Ong)'; 'geert (Geert Rosseel)'; 'hopper (Mark 

Hofmann)'; 'vo (Tom Vo)' 
Subject: widening power in clock spars? 


Warren's examination of power distribution in euterpe found, among other things, that the 
ends of the clock spars tend to be weak spots . 

Although we're making other changes that may be adequate for euterpe, it seems to me that, 
with modest effort, we could modify the clock/bias construction to widen the clock shield 
wires into bigger power distribution wires where there aren't actual clock wires to 
shield. 

With the clock distribution scheme we have, this would give us increasing vertical power 
bussing as one moved away from the mast -- ie, toward the spar ends. 

The only downside I can see to doing this is that we would lose the ability for global 
routing to jog vertically in the clock spars. I don't think this is a serious loss, 
though... in fact, I vaguely remember we decided to disallow that completely anyway. Is 
this true? 

To widen the M3 shield wires, I envision that a mask layer over the clock distribution 
section of the clock spars {extending to just include the outer shield wires) would be 
computed somehow (not sure how, but it seems it shouldn't be too hard), then the 
clock/bias layout would be post-processed by a vlsimm script. I think the following 
script {which assumes the clock area mask is in the pseudo-layer v clock_area_mask' ) would 
do the trick: 

# 

# Widen M3 clock shields horizontally where possible 
# 

# This is done by growing M3 to the left 1 track (20 dbus) and 

# cutting out anything that interferes with a right, top, or bottom 
ft edge of the old M3 . Then the same process is repeated for the 

# right edge. Only M3 covered by the pseudo- layer "clock_area_mask ' 

# is widened, although all M3 is examined for conflicts. 
# 

flatM3 = flatten(M3); 

newM3 = grow (clock_area_mask * flatM3, 20, 0, 0, 0) 

- grow(flatM3, 0, 10, 10, 10); 
flatM3 = flatM3 + newM3; 
newM3 = newM3 

+ grow(clock_area_mask * f latM3 , 0, 0, 20, 0) 
- grow(flatM3, 10, 10, 0, 10); 
flatM3 = flatM3 + newM3 ; 
M3 = M3 + newM3; 
delete newM3 ; 

# 

# Widen V23 as much as possible -- not necessary, but why not? 
# 

# This is done by performing a horizontal grow of V2 3 inside the 

# overlap of M2 and M3 . Use 2 steps of 10 dbu each to avoid shorts . 

# Again, added geometry is limited to the area covered by 

# "clock_area_mask' -- not sure why, just paranoid, I guess. 
# 

overlap = clock_area_mask * flatM3 * flatten(M2); 
flatV23 = flatten(V23) ; 

newV2 3 = grow (grow ( f latV2 3 , 10, 0, 10, 0) * overlap, 

10, 0, 10, 0) * overlap; 
V23 = V2 3 + (newV23 - flatV23) ; 
delete overlap, flatV23, newV23; 
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# Widen V3 4, just like V23 
# 

overlap = clock_area_mask * flatM3 * flatten (M4) ; 
flatV34 = flatten (V34) ; 

newV34 = grow (grow ( flat V3 4 , 10, 0, 10, 0) * overlap, 

10, 0, 10, 0) * overlap,- 
V34 = V34 + (newV34 - flatV34); 
delete overlap, flatV34, newV34 ; 

delete flatM3, clock_area_mask; 

Comments? 


ooooO Ooooo 

(J (_ ) 
\ ( tau ) / 

(_) (_) 
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From: geert (Geert Rosseel) 

Sent: Sunday, January 08, 1 995 6:23 PM 

To: 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'tbr'; 'woody' 

Subject: Top-level Euterpe Timing errors 


Hi, 


Here are the timing violations of the latest top-level run. 
More detailed, info is in : 

/n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards/geert_euterpe- top. stat 
(look for HARD ERROR) 


***** 

dr to nb : about 50 errors 


Warning! Cycle time exceeded by 3.91ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1 

Path After Optimization using cycle time of 926.00: 

dr/drout/muxf f 7_16prblo/u4 (xbmuxf f b7dh24s 24S) Oport : 

q_adQph intDel : 89.60 net: DRprb<4> swg: dh delay: 272 
.4 9ps (force) RC delay: 152. 4 Bps Ids: 1 pcap: 2 0.73ff cap: 

585.58ff (ext) m21en: 0.00 m31en: 5135.00 m4len: 0.00 

nb/mux4_16_prba/u4 (xbmux4dhl6s 16S) Iport : D3_AD0PH 

Oport: q_ad0ph IntDel: 83.80 net: nb/prb<4> swg: dh de 
lay: 119.69ps (force) RC delay: 2 8.18ps Ids: 4 pcap: 44.35ff 

cap: 266.95ff (ext) m21en: 0.00 m31en: 1152.00 m41en: 8 28.00 

nb/mux4_16_prba/u4 (xbmux4dhl6s 16S) iport : D3_AD0PH 

Oport: q_ad0ph IntDel: 83.80 net: nb/prb<4> swg: dh de 
lay: 119.69ps (force) RC delay: 2 8.18ps Ids: 4 pcap: 44.35ff 

cap: 266.95ff (ext) m21en: 0.00 m31en: 1152.00 m4len: 8 28.00 

nb/muxenf f 2_5oq/u0/u0 (xbmuxen2dhl6s 16S) Iport: D1_AD0PH 

Oport: q_adOph IntDel: 72.60 net: nb/muxenf f2_5oq/u0/m 

swg: dh delay: 4.43ps (force) RC delay: 0 . Olps Ids: 1 

pcap: 7.52ff cap: ll,32ff (ext) m2len: 12.00 m3len: 2 
.00 m41en: 0.00 

nb/muxenf f2_5oq/u0/ul (xbffdh2s 2S) Iport: D0_ADMPH 

IntDel: 2 87.30 

Time through Path: 929.91 

* * * * 

nb to uu : about 60 errors 

* * ** 

Warning! Cycle time exceeded by 354. 8 Ops using cycle time of 926.0 0 for 
Iteration 1 HARD ERROR 53 

Path After Optimization using cycle time of 926.00: 

nb/nbctrl/Uareforreturn/uO (xborf fb3df 32s 32S) Oport: 

Q_AD0PF IntDel: 88.00 net: nbWeDXl_N swg: df delay: 926 
.50ps (force) RC delay: 484.28ps Ids: 29 pcap: 139.27ff cap: 

1078. 56ff (ext) m21en: 0.00 m31en: 8539.00 m41en: 0.00 
uu/UclrNbArryLBsyX2/u0 (xborf f3df 4s 4S) Iport: D2_A0PF 

IntDel: 266.30 

Time through Path: 1280.80 

Warning! Cycle time exceeded by H0.23ps using cycle time of 926.00 for 
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. Iteration 1 HARD ERROR 97 

Path After Optimization using cycle time of 926.00: 

nb/f f_4_awa/u0 (xbffbdh24s 24S) Oport : q_and0ph IntDel : 

8 9.60 net: nb/awa_N<0> swg: dh delay: 68.71ps (fo 

rce) RC delay: 21.87ps Ids: 3 pcap: 49.91ff cap: 227.01ff 

(ext) m21en: 0.00 m3len: 1043.00 m4len: 728.00 

nb/buf_4_NBawa/u0 (xbbufdh32s 32S) Iport : D0_ANDMPH 

Oport: q_adOph IntDel: 55.50 net: nbAWaR14<0> 

swg: dh delay: 645.61ps (force) RC delay: 461.8 9ps Ids: 1 

pcap: 8.84ff cap: 1010. 72ff (ext) m2len: 0.00 m31en: 
9108.00 m4len: 0.00 

uu/UnbAWaR15/uO (xbffbdf8s 8S) Iport: D0_ADMPH IntDel: 

176.80 

Time through Path: 1036.23 

***** 

cc to nb : 15 errors 

* * * * 

Warning! Cycle time exceeded by 15.18ps using cycle time of 92 6.00 for 
Iteration 1 HARD ERROR 110 

Path After Optimization using cycle time of 926.00: 

cc/muxff4_lhpb/u0 (xbmuxf fb4df 32s 32S) Oport: Q_AD0PF 

IntDel: 87.80 net: CChpbR13 swg: df delay: 3 02.28ps (f 
orce) RC delay: 98 . 14ps Ids: 8 pcap: 56.32ff cap: 4 83.23ff 

(ext) m2len: 0.00 m31en: 3881.00 m41en: 0.00 

nb/fqcount/Ucout_36/uO (xbor8df32s 32S) Iport: D6_A0PF 

Oport: Q_AND0PF IntDel: 229.10 net: nb/f qcount/cout_N_3_6 

swg: df delay: 50.20ps (force) RC delay: 2 . 92ps Ids: 4 

pcap: 28.77ff cap: 87.67ff (ext) m21en: 0.00 m31en: 19 
7.00 m4len: 3 92.00 

nb/fqcount/Ucout_3/uO (xborf f 14df 6s 6S) Iport: 
D7A0PF IntDel: 271.80 

Time through Path: 941.18 

* ** * 

in gt : 45 errors 

* * * * 

Warning! Cycle time exceeded by 86.35ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 12 3 

Path After Optimization using cycle time of 926.00: 

gt/UgtSnake/Upbbo/ul6 (xbmuxf fb2df 32s 3 2S) Oport: Q_AD0PF 
IntDel: 86.50 net: GIpbb<16> swg: df delay: 4 08.61ps (f 
orce) RC delay: 145.28ps Ids: 5 pcap: 44.20ff cap: 579.46ff 

(ext) m21en: 0.00 m3len: 4866.00 m4len: 0.00 

gt/UgtSnake/UspMtchErly/Uresetrdy_2/u0 (xborl7df32s 32S) 
Iport: D0_AOPF Oport: Q_AND0PF IntDel: 244.20 net: gt/Ug 
t Snake /UspMtchErly/resetrdy_N_2 swg: df delay: 6 . 74ps (force) RC delay: 
0.08ps Ids: 1 pcap: 4.92ff cap: 14.42ff (ext) 

m2len: 0.00 m31en: 13.00 m41en: 82.00 

gt/Ug t Snake /UspMtchErly/Uresetrdy/uO (xborf f3df 2s 2S) 
iport: D2_A0PF IntDel: 2 66.30 

Time through Path: 1012.35 


*** * 

gt to at : 2 errors 
* *** 

Warning! Cycle time exceeded by 1.18ps using cycle time of 92 6.00 for 
Iteration 1 HARD ERROR 170 

Path After Optimization using cycle time of 926.00: 

gt/UsaoutXorR10/u3 (xbffbdf32s 32S) Oport: Q_AD0PF 

IntDel: 91.30 net: GIsaOutR10<19> swg: df delay: 145 

,97ps (force) RC delay: 43 . 15ps Ids: 5 pcap: 34.51ff cap: 

319.41ff (ext) m21en: 0.00 m31en: 2590.00 ra4len: 0.00 

at/UatPaSel/UpaSel9/uO (xbmux3dfl6s 16S) Iport: D1_AD0PH 
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Oport: Q_AND0PF IntDel : 211.10 net: at/paR10_N<9> SW 

g: df delay: 228.41ps (force) RC delay: 22.30ps Ids: 2 pcap : 

14.80ff cap: 215.90ff (ext) ra2len: 0.00 m3len : 1526.00 

m4len: 485.00 

at/Upal509EqfefRll/u0 (xborf f 7df 12s 12S) Iport : 

D0_A0PF IntDel: 250.40 

Time through Path: 927.18 

* * * * 

in uu : 4 00 errors 

* ** * 

Lot's of things like this : Can the mux be merged with the ff ????? 

Warning! Cycle time exceeded by 5 . 51ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 527 

Path After Optimization using cycle time of 926.00: 

uu/UnbDAvailAXO/ul (xbffbdf32s 32S) Oport: Q_AD0PF 

IntDel: 8 9.50 net: uu/nbDAvailAX0<l> swg: df delay: 61. 
lOps (force) RC delay: 5.59ps Ids: 4 pcap: 51. 3 Iff cap: 

143.91ff (ext) m21en: 0.00 m31en: 54.00 m4len: 626.00 

uu/UnbArryRe4X0/u0 (xbor3dh32s 32S) Iport: D1_A0PF 

Oport: q_and0ph IntDel: 138.20 net: uu/nbArryReX0<4 > sw 
g: dh delay: 206.60ps (force) RC delay: 109.12ps Ids: 23 pcap: 

127.79ff cap: 513.99ff (ext) m21en: 0.00 m31en: 1191.00 
m4len: 2671.00 

uu/UnbArryHRDstX0/u2 (xbmux8dhl6s 16S) Iport: 

SEL_A0PEH<4> Oport: q_ad0ph IntDel: 138.80 net: uu/nbArryHRDs 

tX0<2> swg: dh delay: lO.Olps (force) RC delay: 0.36ps Ids: 1 

pcap: 7.52ff cap: 29.92ff (ext) m2len: 4.00 m31en: 21 
2.00 m4len: 0.00 

uu/UnbArryHRDstXl/u2 (xbffdh2s 2S) Iport: D0_ADMPH 

IntDel: 287.30 

Time through Path: 931.51 


**** 

uu to au : 4 0 errors 
* * * * 

Warning! Cycle time exceeded by 64.79ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 944 

Path After Optimization using cycle time of 926.00: 

uu/UwrapAuLvaSelUXRO/uO (xbhrdf32s 32S) Oport: Q_AND0PF IntDel: 
244.80 net: UUwrapAuLvaSelUXR0_N<0> swg: df delay: 256 
.19ps (force) RC delay: 87.14ps Ids: 3 pcap: 22.78ff cap: 

444.96ff (ext) m21en: 0.00 m31en: 3838.00 m41en: 0.00 

au/u2 02/u0 (xbor3dh3 2s 32S) Iport: D1_A0PF Oport: 

q_ad0ph IntDel: 13 8.20 net: au/sfrcl4a_n swg: dh de 

lay: 5.57ps (force) RC delay: 0.3 2ps Ids: 1 pcap: 5 . 99f f 

cap: 27.59ff (ext) m2len: 0.00 m31en: 6.00 m41en: 210.0 0 

au/u208/u0/u0 (xbmuxen2dhl6s 16S) Iport: SEL_AOPEH<0> 

Oport: q_and0ph IntDel: 118.90 net: au/u208/u0/m__N sw 
g: dh delay: 10.93ps (force) RC delay: 0.28ps Ids: 1 pcap: 

8.85ff cap: 26.95ff (ext) ra2len: 0.00 m3len: 27.00 m41 
en: 154.00 

au/u208/u0/ul (xbffdf4s 4S) Iport: D0__ANDMPH 

IntDel: 216.2 0 

Time through Path: 990.79 


uu to rgxmit 
* *★* 
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Warning! Cycle time exceeded by 27.28ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1002 

Path After Optimization using cycle time of 926.00: 

uu/holduu/UinSellCUQ_l/uO (xborf fb7dh24s 24S) Oport: 

q_and0ph IntDel : 89.60 net: uu/inSellCUQ<l> swg: dh de 
lay: 268.31ps (force) RC delay: 145.23ps Ids: 32 pcap: 165.15ff 

cap: 600.75ff (ext) m2len: 0.00 m31en: 2200.00 m41en: 2 156.00 

Uu/UinstUQ/u21 (xbmux3dhl6s 16S) Iport : SEL_A0PEH<1> 

Oport: q_ad0ph IntDel: 114.00 net: UUinstUQ<21> sw 
g: dh delay: 2 63.67ps (force) RC delay: 96.44ps Ids: 2 pcap: 

18.41ff cap: 466.33ff (ext) m21en: 0.00 m3len: 4072.00 
m4len: 0.00 

rgxmit/Ura51RL/u2 (xbffdh24s 24S) Iport: D0_ADMPH 

IntDel: 217.70 

Time through Path: 953.2 8 


* *** 

uu to at 
**** 


Warning 1 Cycle time exceeded by 326.48ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1059 

Path After Optimization using cycle time of 926.00: 

uu/UvldNoXcRll/uO (xborf fb3df 32s 32S) Oport: Q_AD0PF 

IntDel: 86.50 net: UUvldNoXcRll_N swg: df delay: 621 

.74ps (force) RC delay: 261.60ps Ids: 13 pcap: 114.39ff cap: 

797.16ff (ext) m21en: 0.00 m31en: 6207.00 m4len: 0.00 

at/Uatpadcd/UvldNonNbSt_3/u0 (xborl4df3 2s 3 2S) Iport: 
D6_A0PF Oport: Q_AND0PF IntDel: 224.30 net: at/Uatpadcd/v 
ldNonNbSt_N_3 swg: df delay: 32 . 94ps (force) RC delay: 2 . 54ps 
Ids: 2 pcap: 10.63ff cap: 74.83ff (ext) m2len: 0.00 m 
31en: 331.00 m41en: 311.00 

at/Uatpadcd/UsrWrStb/uO (xborf f2dh2s 2S) Iport: 
DO_A0PF IntDel: 287.00 

Time through Path: 1252.48 


* * * * 

NEXT SET IS SAME SIGMAL 

* * * 
P* 

* * ** 

uu to cdio 

* * * * 

Warning! Cycle time exceeded by 256.25ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1190 

Path After Optimization using cycle time of 926.00: 

uu/UetaBf frdUT/uO (xbffbdh24s 24S) Oport: q_and0ph 

IntDel: 89.20 net: UUetaUT_N<0> swg: dh delay: 875 

.95ps (force) RC delay: 607.43ps Ids : 9 pcap: 63 . 96f f cap: 

1176. 06ff (ext) m21en: 0.00 m31en: 10110.00 m4len: 0.00 

cdio/UwrCtlAa/uO (xbhrdh2s 2S) Iport: D0_AND0PH 

IntDel: 217.10 

Time through Path: 1182.25 

**** 

uu to mc 
*** * 

arning! Cycle time exceeded by 256.25ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1189 

Path After Optimization using cycle time of 926.00: 
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uu/UetaBf frdUT/uO (xbffbdh24s 24S) Oport: q_andOph 

IntDel: 89.20 net: UUetaUT_N<0> swg: dh delay: 875 

. 95ps (force) RC delay: 607.43ps Ids: 9 pcap : 63.96ff cap: 

1176. 06ff (ext) m21en: 0.00 m31en: 10110.00 m4len: 0.00 

mc/u206/u0 (xbhrdh2s 2S) Iport : D0_AND0PH 

IntDel: 217.10 

Time through Path: 1182.25 


uu to gt 
*** * 


Warning! Cycle time exceeded by 958.02ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1215 

Path After Optimization using cycle time of 926.00: 

uu/UetaBf frdUT/u2 (xbffbdf32s 32S) Oport: QAND0PF 

IntDel: 89.50 net: UUetaUT_N<2> swg: df delay: 12 8 

2.12ps (force) RC delay: 794.83ps Ids: 15 pcap: 90.22ff cap: 

1350. 93ff (ext) m2len: 0.00 m3len: 11461.00 m4len: 0.00 

gt/Ugt Snake /UmuxCtl/Uahold_l/uO (xbor5df32s 32S) Iport: 
D0_A0PF Oport: Q_AND0PF IntDel: 172.50 net: gt/UgtSnake/U 
muxCtl/ahold_N_l swg: df delay: 5 9. 6 Ops (force) RC delay: 5.8 8ps 

Ids: 6 pcap: 34.73ff cap: 121.53ff (ext) m2len 
: 0.00 m3len: 66.00 m4len: 802.00 

gt /Ugt Snake /UmuxCtl/Uahl/uO (xborff5dh8s 8S) 

Iport: D2_A0PF IntDel: 28 0.30 

Time through Path: 1884.02 

* * ** 

uu to dr 


Warning! Cycle time exceeded by 772.25ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1234 

Path After Optimization using cycle time of 926.00: 

uu/UetaBffrdUT/u2 (xbffbdf32s 32S) Oport: Q_AND0PF 

IntDel: 90.00 net: UUetaUT_N<2> swg: df delay: 125 

3.55ps (force) RC delay: 798.71ps Ids: 15 pcap: 95 . 06f f cap: 

1355. 77ff (ext) m2len: 0.00 m3len: 11461.00 m4len: 0.00 

dr/muxf f 2tagl/ul (xbmuxf f 2dh3s 3S) Iport: 

SEL_A0PEH<0> IntDel: 354.70 

Time through Path: 1698.25 


**** 

uu to au 


Warning! Cycle time exceeded by 48.46ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1240 

Path After Optimization using cycle time of 926.00: 

uu/UtauOutUU/uO (xbffedh24s 24S) Oport: q_adlph IntDel: 

127.90 net: UUtauUU swg: dh delay: 559.26ps (force) RC 

delay: 393.15ps Ids: 16 pcap: 212.10ff cap: 1005. 42ff (ext) 

m2len: 0.00 m3len: 7212.00 m4len: 0.00 

au/zOO/uO (xbffedh3s 3S) Iport: D0_ANDMPH 

IntDel: 287.30 

Time through Path: 974.46 


* * * * 

uu to hz 

* * * * 

Warning! Cycle time exceeded by 49.79ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1252 

Path After Optimization using cycle time of 926.00: 

uu/UtauOutUU/uO (xbffedh24s 24S) Oport: q_andlph IntDel: 

12 7.90 net: UUtauUU_N swg: dh delay: 560.59ps (force) RC 
delay: 394.28ps Ids: 16 pcap: 212.10ff cap: 1006. 74ff (ext) 
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m21en: 0.00 m3len: 7224.00 m4len: 0.00 

hz/zzxx/uO (xbffdh2s 2S) Iport : D0_ANDMPH 

IntDel: 287.30 

Time through Path: 975.79 

* * * * 

uu to nb 
*** * 

Warning! Cycle time exceeded by 4 9.79ps using cycle time of 926.00 for 
Iteration 1 HARD ERROR 1253 

Path After Optimization using cycle time of 926.00: 

uu/UtauOutUU/uO (xbffedh24s 24S) Oport : q_andlph IntDel: 

127.90 net: UUtauUU_N swg: dh delay: 560.59ps (force) RC 

delay: 394.28ps Ids: 16 pcap: 212.10ff cap: 1006. 74ff (ext) 

m2len: 0.00 m3len: 7224.00 m4len: 0.00 

nb/hrbufO/uO (xbffedh2s 2S) Iport: D0ADMPH IntDel: 

287.30 

Time through Path: 975.79 


* *** 

iq to uu to rgxmit 
**** 

Warning! Cycle time exceeded by 13.42ps using cycle time of 926.00 for 
Iteration 1 HARD error 1265 

Path After Optimization using cycle time of 926.00: 

iq/UinstLQS/u8 (xbmuxf f b8dh24s 24S) Oport: q_ad0ph IntDel: 

89.60 net: IQinstQS<8> swg: dh delay: 3 71.94ps (f 

orce) RC delay: 226.33ps Ids: 1 pcap: 21.09ff cap: 712.11ff 

(ext) m21en: 0.00 m31en: 6282.00 m41en: 0.00 

uu/UinstUQ/u8 (xbmux3dhl6s 16S) Iport: D2_AD0PH Oport: 

q_and0ph IntDel: 74.00 net: UUinstUQ_N<8> swg: dh de 

lay: 186.18ps (force) RC delay: 55.49ps Ids: 2 pcap: 17.82ff 

cap: 354.97ff (ext) m2len: 0.00 m3len: 3065.00 m4len: 0 .00 

rgxmit /Urc51RL/ul (xbffdh24s 24S) Iport: D0_ANDMPH 

IntDel: 217.7 0 

Time through Path: 93 9.42 

**** 

in hcO 
**** 

Bunch of errors 
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From: tbr 

Sent: Sunday, January 08, 1995 6:31 PM 

To: 'geert (Geert Rosseel)' 

Cc: 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'woody' 

Subject: Top-level Euterpe Timing errors 
Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Sun Jan 8): 
Hi, 

Here are the timing violations of the latest top-level run. 
How does the total number compare to last time? 
Tim 
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From: tbr (Tim B. Robinson) 

Sent: Sunday, January 08, 1995 6:31 PM 

To: 'geert (Geert Rosseel)' 

Cc: 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'woody' 

Subject: Top-level Euterpe Timing errors 


Geert Rosseel wrote (on Sun Jan 8) : 


Hi, 

Here are the timing violations of the latest top-level run. 
How does the total number compare to last time? 
Tim 
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From: tbr 

Sent: Sunday, January 08, 1995 9:46 PM 

To: Tom Eich' 

Subject: Pandora 1/6 meeting actions 

Follow Up Flag: Follow up 

Flag Status: Red 


I think it would be worth posting your notes to pandora. 

Some things like the SIMM choice may provoke some discussion. 

Tim 


Exhibit CIO 


Page 93 of 356 


Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Sunday, January 08, 1995 10:46 PM 

'torn' 

'geeif; 'hopper'; 'ong'; 'vo' 

Re: widening power in clock spars? 


Tom L . writes: 


>Warren's examination of power distribution in euterpe found, among 
>other things, that the ends of the clock spars tend to be weak spots. 
>Although we're making other changes that may be adequate for euterpe, 
>it seems to me that, with modest effort, we could modify the clock/bias 
>construction to widen the clock shield wires into bigger power 
distribution wires where there aren't actual clock wires to shield. 
>With the clock distribution scheme we have, this would give us 
>increasing vertical power bussing as one moved away from the mast -- 
>ie, toward the spar ends. 
> 

>The only downside I can see to doing this is that we would lose the 
>ability for global routing to jog vertically in the clock spars. I 
>don't think this is a serious loss, though... in fact, I vaguely 
>remember we decided to disallow that completely anyway. Is this true? 

Actually, the current routing strategy I'm working with permits jogging 
in the clock spars; the only thing that's disallowed is M3 under the 
power pad regions, to avoid long vertical wires which get hit repeatedly 
by many power pads. 

These regions near the extreme ends of the clock spars are also used by 
the router to wire up the VFF* custom domain bias signals, and we do have 
some extreme congestion in these regions near the north ends of spars 
3 & 5 . The VFF targets aren't easy to get to, and might be rendered 
unreachable if all the M3 resource were filled in with power bussing. 

>To widen the M3 shield wires, I envision that a mask layer over the 
>clock distribution section of the clock spars (extending to just 
> include the outer shield wires) would be computed somehow (not sure 
>how, but it seems it shouldn't be too hard), then the clock/bias layout 
>would be post-processed by a vlsimm script. I think the following 
> script (which assumes the clock area mask is in the pseudo- layer 
>" c 1 oc kar ea_ma sk 1 ) would do the trick: 

[sophisticated vlsimm script snipped] 

>Comments? 

Let's examine the final Calliope route and see how the VFF hookups 
were made, and also to what extent global routing made use of these 
regions. We can also look at the current Euterpe route, but it doesn't 
yet have Cerberus or the VFF hookups in place. If it looks like we can 
do without those areas for routing, then I would support beefing up 
the power bussing in those areas (although it sounds like a fix to 
the hemming cell would address the problem identified by Warren) . If 
it looks like these areas are useful for global routing, then I would 
be more reluctant to give them up, especially with the congestion we're 
grappling with in the north areas right now. 


- Kurt 
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From: mws (Mark Semmelmeyer) 

Sent: Monday, January 09, 1995 3:56 AM 

To: 'Geert Rosseel' 

Cc: 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)*; 'hopper (Mark Hofmann)'; 

'mws (Mark Semmelmeyer)'; 'tbr (Tim B. Robinson)'; 'woody (Jay Tomlinson)' 
Subject: Re: Top-level Euterpe Timing errors 


> * * ** 

> nb to uu : about 60 errors 

> * *** 

> 

> Warning! Cycle time exceeded by 354. 8 Ops using cycle time of 926.00 

> for 

Iteration 1 HARD ERROR 53 

> Path After Optimization using cycle time of 926.00: 

> nb/nbctrl/Uareforreturn/uO (xborf fb3df 32s 32S) Oport: 
Q_AD0PF IntDel: 88.00 net: nbWeDXl_N swg : df delay: 926 

> .50ps (force) RC delay: 484.28ps Ids: 29 pcap : 139.27ff cap: 
1078. 56ff (ext) m2len: 0.00 m31en: 8539.00 m41en: 0.00 
uu/UclrNbArryLBsyX2/uO (xborf f3df4s 4S) Iport : D2_A0PF 
IntDel: 266.30 

> Time through Path: 128 0.80 

Bill has already taken out the buffer, but my conversion of this to half -swing isn't in 
until my next release. Maybe I will need two copies as I have about 18-20 loads inside? 


> Warning! Cycle time exceeded by 110.23ps using cycle time of 92 6.00 

> for 

Iteration 1 HARD ERROR 97 

> Path After Optimization using cycle time of 926.00: 

> nb/ff_4_awa/u0 (xbffbdh24s 24S) Oport: g_and0ph IntDel: 
89.60 net: nb/awa_N<0> swg: dh delay: 68.71ps (fo 

> rce) RC delay: 21.87ps Ids: 3 pcap: 49.91ff cap: 227.01ff 
(ext) m21en: 0.00 m31en: 1043.00 m4len: 728.00 

> nb/buf_4_NBawa/uO (xbbufdh32s 32S) Iport: D0_ANDMPH 
Oport: q_ad0ph IntDel: 55,50 net: nbAWaR14<0> 

> swg: dh delay: 645.61ps (force) RC delay: 461.89ps Ids: 1 
pcap: 8.84ff cap: 1010. 72ff (ext) m2len: 0.00 m31en: 

> 9108.00 m4len: 0.00 

> uu/UnbAWaR15/u0 (xbffbdf8s 8S) Iport: D0_ADMPH IntDel: 
176.80 

> Time through Path: 1036.23 

This will be close, but if billz gives me a separate (from his 
internals) flop copy without the buffer, I think it will make it. 


> **** 

> in uu : 400 errors 

> * *** 

> 

> Lot's of things like this : Can the mux be merged with the ff ????? 
Yes, this is an oversight. I will fix it. 


> * * * * 

> uu to au : 4 0 errors 

> * * * * 

> 

> Warning! Cycle time exceeded by 64.79ps using cycle time of 926.00 

> for 

Iteration 1 HARD ERROR 944 

> Path After Optimization using cycle time of 926.00: 

> uu/UwrapAuLvaSelUXRO/uO (xbhrdf32s 32S) Oport: Q_AND0PF IntDel: 
244.80 net: UUwrapAuLvaSelUXR0_N<0> swg: df delay: 256 
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> .19ps {force) RC delay: 87.14ps Ids: 3 pcap: 22.78ff cap: 
444.96ff (ext) m21en: 0.00 m3len: 3838.00 m41en: 0.00 

> au/u202/u0 (xbor3dh3 2s 3 2S) Iport: D1_A0PF Oport : 
q_ad0ph IntDel : 138.20 net: au/sf rcl4a_n swg: dh de 

> lay: 5.57ps (force) RC delay: 0.32ps Ids: 1 pcap: 5.99ff 
cap: 27.59ff (ext) m2len: 0.00 m31en: 6.00 m4len: 210.0 

> 0 

> au/u208/u0/u0 (xbmuxen2dhl6s 16S) Iport: SEL_A0PEH<0> 
Oport: q_and0ph IntDel; 118.90 net: au/u208/u0/m_N sw 

> g: dh delay: 10.93ps (force) RC delay: 0.28ps Ids: 1 pcap: 
8.85ff cap: 26.95ff (ext) m21en: 0.00 m3len: 27.00 ra4l 

> en: 154.00 

> au/u208/u0/ul (xbffdf4s 4S) Iport: D0_ANDMPH 
IntDel: 216.20 

> Time through Path: 990.79 

I think this was once a 2 tick path because uu sent it out of an hr. 

UU could decode the signal earlier so that the driving flop could be local. However, 
because a muxenff macro was used, it really is a "3 gate" path and is going to always 
remain a little stressed. 


> * * * * 

> uu to rgxmit 

> * * ** 

> 

> Warning! Cycle time exceeded by 27.28ps using cycle time of 926.00 

> for 

Iteration 1 HARD ERROR 10 02 

> Path After Optimization using cycle time of 926.00: 

> uu/holduu/UinSellCUQ_l/uO (xborf fb7dh24s 24S) Oport: 
q_and0ph IntDel: 89.60 net: uu/inSellCUQ<l> swg: dh de 

> lay: 268.31ps (force) RC delay: 145.23ps Ids: 32 pcap: 165.15ff 
cap: 600.75ff (ext) m2len: 0.00 m3len: 2200.00 m4len: 2 

> 156.00 

> uu/UinstUQ/u21 (xbmux3dhl6s 16S) Iport: SEL_A0PEH<1> 
Oport: q_ad0ph IntDel: 114.00 net: UUinstUQ<21> sw 

> g: dh delay: 263.67ps (force) RC delay: 96.44ps Ids: 2 pcap: 
18.41ff cap: 466.33ff (ext) m21en: 0.00 m3len: 4072.00 

> m4len: 0.0 0 

> rgxmit /Ura51RL/u2 (xbffdh24s 24S) Iport: D0_ADMPH 
IntDel: 217.70 

> Time through Path: 953.28 

My offer to geert still stands to send this (sometimes iq- ->) uu— >rgxmit- - >rgcr path 
without going through rgxmit. 


> * + * * 

> uu to at 

> **** 

> 

> Warning! Cycle time exceeded by 326.4 8ps using cycle time of 926.0 0 

> for 

Iteration 1 HARD ERROR 1059 

> Path After Optimization using cycle time of 926.00: 

> uu/UvldNoXcRll/uO (xborf fb3df 32s 32S) Oport: QAD0PF 
IntDel: 86.50 net: UUvldNoXcRll_N swg: df delay: 621 

> .74ps (force) RC delay: 261.60ps Ids: 13 pcap: 114.39ff cap: 
797.16ff (ext) m21en: 0.00 m31en: 6207.00 m41en: 0.00 

> at/Uatpadcd/UvldNonNbSt_3/u0 (xborl4df32s 32S) Iport: 
D6_A0PF Oport: Q_AND0PF IntDel: 224.30 net: at/Uatpadcd/v 

> ldNonNbSt_N_3 swg: df delay: 32.94ps (force) RC delay: 2 . 54ps 
Ids: 2 pcap: 10.63ff cap: 74.83ff (ext) m2len: 0.00 m 

> 3len: 331.00 m41en: 311.00 

> at/Uatpadcd/UsrWrStb/uO (xborf f2dh2s 2S) Iport: 
D0_A0PF IntDel: 287.00 

> Time through Path: 1252.4 8 

woody was hinting at a secret plan to fix this. 
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> *** * 

> iq to uu to rgxmit 

> **** 

> 

> Warning! Cycle time exceeded by 13.42ps using cycle time of 926.00 

> for 

Iteration 1 HARD ERROR 1265 

> Path After Optimization using cycle time of 926.00: 

> iq/UinstLQS/u8 (xbmuxf f b8dh24s 24S) Oport : q_ad0ph IntDel: 
89.60 net: IQinstQS<8> swg: dh delay: 371.94ps (f 

> orce) RC delay: 226.33ps Ids: 1 pcap: 2l.09ff cap: 712.11ff 
(ext) m21en: 0.00 m3len: 6282.00 m41en: 0.00 

> Uu/UinstUQ/u8 (xbmux3dhl6s 16S) Iport : D2_AD0PH Oport: 
q_andOph IntDel: 74.00 net: UUinstUQ_N<8 > swg: dh de 

> lay: 186.18ps (force) RC delay: 55.49ps Ids: 2 pcap: 17.82ff 
cap: 354.97ff (ext) m21en: 0.00 m31en: 3065.00 m41en: 0 

> . 00 

> rgxmit/Urc51RL/ul (xbffdh24s 24S) Iport: D0_ANDMPH 
IntDel: 217.70 

> Time through Path: 93 9.42 

My offer to geert still stands to send this (sometimes iq- ->)uu-->rgxmit-->rgcr path 
without going through rgxmit. 
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From: doi (Derek Iverson) 

Sent: Monday, January 09, 1995 4:30 PM 

To: 'torn (Tom Laidig)' 

Cc: 'lisar 1 ; 'geert (Geert Rosseel)'; Tim B. Robinson' 
Subject: Re: BOM trouble 

Tom Laidig writes: 

> Tim B. Robinson writes: 

> (When I did agetbom in the proteus snapshot I got the following 

> jwarning: 
>l 

> | WARNING SUMMARY 

> )/n/auspex/s23/euterpe-proteus-cp/ged/sc: Directory scxbcgdrl is not part of the BOM (but still present locally) 

> 

> I'll let doi comment on getbom's behavior (FYI, doi, that directory only 

> contained 4 files, all under cvs control). I have removed scxbcgdrl, 

> since it is, in fact, obsolete. It was deleted in BOM revision 45.0 

> dated 12/21: 

Getbom was modified on 12/13/94 so that directories that were no longer 
mentioned in the BOM being extracted and were under CVS control (i.e. had 
a CVS directory) are not removed unless the -K option is used. 

When 'chip' extracts stuff as a result of a releasebom, it uses the -K 
option. 

Why? Tom Vo discovered that if you cvs add a directory (creates the CVS 
directory within the target directory) and then go about creating 
all sorts of source files (but have not yet 'cvs added' them), a getbom 
at this point would remove all your source files. 

Getbom tries real hard not to remove things it shouldn't so if a directory 
is supposed to be removed, it runs 'cvs status' on the entire subtree 
to make sure everyting is at least 'up-to-date' before removing it. As 
you might have already guessed, new files that have not been added to the 
repository look just like objects or intermediate files, so they are 
removed. 

If you want this behaviour, you will have to use the -K option, 
doi 
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Sent: 

To: 

Cc: 


Subject: 


From: 


ong (Warren R. Ong) 

Monday, January 09, 1995 6:16 PM 

'Kurt Wampler* 

Vanthof (Dave Van't Hot)'; 'geert (Geert Rosseel)*; 'rich (Rich McCauley)'; 'tbr (Tim B. 

Robinson)'; Vikki (Vikki Vu)' 

Re: Please Lock Down "iobyteO" & "ioquadctrl" 


>From Kurt Wampler . . . 

@ 

® Warren Ong writes: 
@ 

@ >Power Improvement has been done to the layouts of iobyteO and @ >ioquadctrl. They have 
passed lvs and drc . Dave, please lock down @ > @ > iobyteO @ > ioquadctrl @ > @ >Since 
there are related cells that are generated by gards, perhaps @ >they need to be re-routed 
- Kurt? 
@ 

@ I've updated the /u/chip/ version of the ioquadstdc gardswart; it 
definitely 

@ changed the routing, but it did route to completion. It's probably 
time 

@ now to LVS iobyte and make sure that the whole cell is clean & self- 
@ consistent. 

@ 

@ After iobyte passes LVS /DRC, I assume Tim will getbom these changes in 
@ euterpe's proteus snapshot and kick off a gardswart build in the 
snapshot . 

@ 

They have passed drc and lvs after the latest route on Friday. 


Warren. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


craig 

Monday, January 09, 1995 6:46 PM 
'abbott@MicroU nity.com'; 'agc@MicroUnity.com' 

'graham@MicroUnity.com'; 'hessam@MicroUnity.com'; 'jt@MicroUnity.com'; 

'pandora@MicroUnity.com'; 'tony@MicroUnity.com'; 'yves ©aphrodite* 

Bandwidth Calculations for HighRes RGB display (was RE: Euterpe housing containing 

Calliope) 


SUMMARY: 108 MHz display uses about 25% of one thread for a feasable 
imp lenient at ion using Euterpe/Calliope system architecture. 
Simulation of microarchitectural effects is warranted. 

I have for a long time assumed that a high resolution RGB display would be the I/O (really 
O) device which had the highest bandwidth requirements. (2.4 Gb/sec ATM is about twice as 
much bandwidth per link, though.) The calculation below affirms that the Euterpe- 
Calliope architecture should permit a feasable implementation of an RGB display. 

When all of the display is static, using a frame-buffer is a good approach. However, when 
only some of the display is static, using the 

DRAM->Calliope copying avoids DRAM- to -DRAM copying for double-buffered 

displays and scrolling windows. Scrolling a near -full -screen window in a frame's time on a 
frame-buffer actually requires three times the DRAM bandwidth of a DRAM->Calliope system. 
The non-frame buffer system also permits fully- animated dragging (and even resizing!) of 
windows . 

Run- length encoding of constant- color regions can significantly reduce the average 
bandwidth, whether for screen background, or blank regions at the end and between text 
lines. Also, text windows can be read from DRAM at 1-8 bits/pixel and expanded in Euterpe, 
further reducing average DRAM bandwidth. Window boundaries can cause a modest increase in 
average DRAM bandwidth. 

1024*1280*72 Hz without blank and sync time requires 94 MHz average rate; 108 MHz is a 
reasonable peak pixel rate, though it 1 s a little low for the resolution and refresh rate 
indicated, considering the blank and sync time used on other displays, causing a lower 
refresh rate, and/or fewer pixels. For example, NeXT's displays were 1130x832x68 Hz => 68 
MHz average rate, with a 100 Mhz peak pixel rate. 108 Mhz is only 8% higher, while the 
number of pixels is about 40% higher and the refresh rate is 6% higher. 

Presumably, the choice of pixel rate is a noise issue,- I believe we could live with 108 
MHz if we had to. Using the same margin between peak and average as the NeXT displays, we 
get a 73.4 MHz average displayable pixel rate. This assumes that generation of blanking 
and sync signals can be expressed either as run- length encoded or as mostly preset values 
in the Calliope buffer memory. 

73.4 MHz * 3 bytes/pixel yields a 220 MB/sec data rate. Hexlet loads and stores imply a 
copy rate of 13.8 Mhexlets/sec . This is about 5% of a 1.08 GHz single- threaded machine, 
or about 25% of one of the five threads of a pent a thread machine, assuming the copy rate 
is limited by the store rate of 1 store/4 cycles. I'd conclude that that the assertion 
that this is CPU bound is weak. 

However, the Hermes channel, which requires 12 cycles for a 8 byte write, becomes highly 
utilized: a 33 0 MB/sec raw data rate is required in the path from Euterpe to Calliope, 
using up 30% of the available bandwidth. Assuming the data comes from Mnemosyne memory, an 
additional 7.5% on each channel is used to transmit the Hermes read commands, making the 
outgoing Hermes channel that contains Calliope and 2 Mnemosynes 38% utilized. Depending 
upon whether the Calliope or Mnemosyne devices are reached first in the ring, this is the 
worst case (when Calliope comes first) . 

If Mnemosynes are first, the utilization reaches 43% as the 6 -byte read commands are 
replaces with 10 -byte read responses. 

The return path utilization reaches only 17%, as most packets are then 2 -byte write 
responses . 

Calliope first: E C M M E 

38% 12% 14% 17% 
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Mnemosyne first :E M M C E 

38% 40% 43% 17% 

Using Euterpe memory, the peak 400 MB/sec data rate of 100 MHz SDRAMs would be 55% 
utilized, which is uncomfortably high. (However, the use of page-mode can also be high, 
which compensates.) 4 Mnemosyne memories can provide memory bandwidth about twice as 
high, which brings memory utilization back below 30% peak/average. Much more (4x) 
bandwidth would be available from 4 Mnemosynes using SDRAMs . 

With one thread issuing a store and a load every 20 cycles, the Hermes channel output must 
sustain 12+6 = 18 Hermes cycles at peak, so the details of the design of the NB load 
buffer are critical. In addition, this rate must match the capacity of Mnemosyne to accept 
the load operations to DRAM , which is also in the same ballpark figure: 
1/4 of loads (distributing to the 4 Mnemosynes) each 80 cycles. 

Simulation of real code is likely to be worthwhile, as there is substantial opportunity 
for microarchitecture interactions that could further limit performance. Notably, the 
gextract operation may be critical to realignment of data between DRAM and Calliope. 

Regards , 
Craig 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, January 09, 1995 7:14 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/gt BOM 67.0 initiated by woody completed @ Mon Jan 9 17:11:42 
PST 1995 with exit status 0.. chip 
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From: Craig Hansen [craig@gaea.microunity.com] 

Sent: Monday, January 09, 1995 7:46 PM 

To: 'abbott@MicroUnity.com'; 'agc@MicroUnity.com' 

Cc: 'graham@MicroUnity.com'; 'hessam@MicroUnity.com'; 'jt@MicroUnity.com'; 

'pandora@MicroUnity.com'; l tony@MicroUnity.com'; 'yves@aphrodite' 
Subject: Bandwidth Calculations for HighRes RGB display (was RE: Euterpe housing containing 

Calliope) 


SUMMARY: 108 MHz display uses about 25% of one thread for a feasable 
implementation using Euterpe /Calliope system architecture. 
Simulation of microarchitectural effects is warranted. 

I have for a long time assumed that a high resolution RGB display would be the I/O (really 
0) device which had the highest bandwidth requirements. {2.4 Gb/sec ATM is about twice as 
much bandwidth per link, though.) The calculation below affirms that the Euterpe- 
Calliope architecture should permit a feasable implementation of an RGB display. 

When all of the display is static, using a frame -buffer is a good approach. However, when 
only some of the display is static, using the 

DRAM->Calliope copying avoids DRAM -to- DRAM copying for double-buffered 

displays and scrolling windows. Scrolling a near- full- screen window in a frame's time on a 
frame-buffer actually requires three times the DRAM bandwidth of a DRAM- > Calliope system. 
The non-frame buffer system also permits fully- animated dragging {and even resizing!) of 
windows . 

Run- length encoding of constant -color regions can significantly reduce the average 
bandwidth, whether for screen background, or blank regions at the end and between text 
lines. Also, text windows can be read from DRAM at 1-8 bits /pixel and expanded in Euterpe, 
further reducing average DRAM bandwidth. Window boundaries can cause a modest increase in 
average DRAM bandwidth. 

1024*1280*72 Hz without blank and sync time requires 94 MHz average rate; 108 MHz is a 
reasonable peak pixel rate, though it's a little low for the resolution and refresh rate 
indicated, considering the blank and sync time used on other displays, causing a lower 
refresh rate, and/or fewer pixels. For example, NeXT's displays were 113 0x832x68 Hz => 68 
MHz average rate, with a 10 0 Mhz peak pixel rate. 108 Mhz is only 8% higher, while the 
number of pixels is about 40% higher and the refresh rate is 6% higher. 

Presumably, the choice of pixel rate is a noise issue; I believe we could live with 108 
MHz if we had to. Using the same margin between peak and average as the NeXT displays, we 
get a 73.4 MHz average displayable pixel rate. This assumes that generation of blanking 
and sync signals can be expressed either as run- length encoded or as mostly preset values 
in the Calliope buffer memory. 

73.4 MHz * 3 bytes/pixel yields a 220 MB/sec data rate. Hexlet loads and stores imply a 
copy rate of 13.8 Mhexlets/sec . This is about 5% of a 1.08 GHz single- threaded machine, 
or about 25% of one of the five threads of a pentathread machine, assuming the copy rate 
is limited by the store rate of 1 store/4 cycles. I'd conclude that that the assertion 
that this is CPU bound is weak. 

However, the Hermes channel, which requires 12 cycles for a 8 byte write, becomes highly 
utilized: a 330 MB/sec raw data rate is required in the path from Euterpe to Calliope, 
using up 30% of the available bandwidth. Assuming the data comes from Mnemosyne memory, an 
additional 7.5% on each channel is used to transmit the Hermes read commands, making the 
outgoing Hermes channel that contains Calliope and 2 Mnemosynes 38% utilized. Depending 
upon whether the Calliope or Mnemosyne devices are reached first in the ring, this is the 
worst case (when Calliope comes first) . 

If Mnemosynes are first, the utilization reaches 43% as the 6 -byte read commands are 
replaces with 10 -byte read responses. 

The return path utilization reaches only 17%, as most packets are then 2-byte write 
responses . 

Calliope first: E C M M E 

38% 12% 14% 17% 
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Mnemosyne first :E M M C E 

38% 40% 43% 17% 

Using Euterpe memory, the peak 40 0 MB/ sec data rate of 10 0 MHz SDRAMs would be 55% 
utilized, which is uncomfortably high. (However, the use of page-mode can also be high, 
which compensates.) 4 Mnemosyne memories can provide memory bandwidth about twice as 
high, which brings memory utilization back below 30% peak/average. Much more (4x) 
bandwidth would be available from 4 Mnemosynes using SDRAMs. 

With one thread issuing a store and a load every 2 0 cycles, the Hermes channel output must 
sustain 12+6 = 18 Hermes cycles at peak, so the details of the design of the NB load 
buffer are critical. In addition, this rate must match the capacity of Mnemosyne to accept 
the load operations to DRAM, which is also in the same ballpark figure: 
1/4 of loads (distributing to the 4 Mnemosynes) each 80 cycles. 

Simulation of real code is likely to be worthwhile, as there is substantial opportunity 
for microarchitecture interactions that could further limit performance. Notably, the 
gextract operation may be critical to realignment of data between DRAM and Calliope. 

Regards , 
Craig 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 
Monday, January 09, 1995 9:33 PM 
'Craig Hansen' 

'abbott@MicroUnity.com'; 'agc@MicroUnity.com'; 'graham@MicroUnity.com'; 
'hessam@MicroUnity.com'; 'jt@MicroUnity.com'; 'pandora@MicroUnity.com'; 
'tony@MicroUnity.com'; 'yves@aphrodite' 

Bandwidth Calculations for HighRes RGB display (was RE: Euterpe housing containing 
Calliope) 


Craig Hansen wrote (on Mon Jan 9) : 


SUMMARY: 108 MHz display uses about 25% of one thread for a feasable 
implementation using Euterpe/Calliope system architecture. 
Simulation of microarchitectural effects is warranted. 


<snip> 


1024*12 80*72 Hz without blank and sync time requires 94 MHz average 
rate; 108 MHz is a reasonable peak pixel rate, though it's a little 
low for the resolution and refresh rate indicated, considering the 
blank and sync time used on other displays, causing a lower 
refresh rate, and/or fewer pixels. For example, NeXT's displays 
were 1130x832x68 Hz => 68 MHz average rate, with a 100 Mhz peak pixel 
rate. 108 Mhz is only 8% higher, while the number of pixels is about 
40% higher and the refresh rate is 6% higher. 

I think your peak rate is somewhat optimistic here. I am familiar with one system (I 
designed it :-) ) which was 1280*1024*60Hz and had a peak rate of 110MHz . That was a long 
time ago though and I think the trend to higher refresh rates is offset to some extent by 
better monitors with lower retrace time allowing a higher portion of the time to carry 
active video. Even so I think 108MHz will limit either the pixel count or the refresh 
rate. This would also depend on just how we intend to generate sync and blanking signals. 
Clearly the approach of our current design (and I think if we are honest, our 
architecturally pure approach) would have us move the problem to software and require 
additional in band data which in the extreme case would make the average equal to the 
peak. 

Presumably, the choice of pixel rate is a noise issue; I believe 
we could live with 108 MHz if we had to. Using the same 
margin between peak and average as the NeXT displays, we get 
a 73.4 MHz average displayable pixel rate. This assumes that 
generation of blanking and sync signals can be expressed either 
as run- length encoded or as mostly preset values in the Calliope 
buffer memory. 

I agree, all we really need is some minimal amount of framing information in the stream 
and simple hardware and fifo buffering can reconstruct the full signal. 

<snip again> 

However, the Hermes channel, which requires 12 cycles for a 8 byte 
write, becomes highly utilized: a 330 MB/sec raw data rate is 
required in the path from Euterpe to Calliope, using up 3 0% of 
the available bandwidth. Assuming the data comes from Mnemosyne 
memory, an additional 7.5% on each channel is used to 

transmit the Hermes read commands, making the outgoing Hermes channel 

that contains Calliope and 2 Mnemosynes 3 8% utilized. Depending 

upon whether the Calliope or Mnemosyne devices are reached first 

in the ring, this is the worst case (when Calliope comes first) . 

If Mnemosynes are first, the utilization reaches 43% as 

the 6-byte read commands are replaces with 10-byte read responses. 

The return path utilization reaches only 17%, as most packets 

are then 2 -byte write responses. 
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Correction here. Write operations take 14 bytes, not 12, so the bandwidth needed is 
385MB/S not 330, 


Calliope first: E C M M E 

38% 12% 14% 17% 


Mnemosyne first :E 


■M- 


M- 


C 


E 


38% 


40% 


43% 


17% 


Using Euterpe memory, the peak 4 00 MB/ sec data rate of 100 MHz SDRAMs 
would be 55% utilized, which is uncomfortably high. (However, the use 
of page-mode can also be high, which compensates.) 4 Mnemosyne 
memories can provide memory bandwidth about twice as high, which 
brings memory utilization back below 3 0% peak/average. Much more (4x> 
bandwidth would be available from 4 Mnemosynes using SDRAM s . 

With one thread issuing a store and a load every 2 0 cycles, the Hermes 
channel output must sustain 12+6 = 18 Hermes cycles at peak, so the 
details of the design of the NB load buffer are critical. In addition, 
this rate must match the capacity of Mnemosyne to accept the load 
operations to DRAM, which is also in the same ballpark figure: 
1/4 of loads (distributing to the 4 Mnemosynes) each 80 cycles. 

Can you clarify this please? First, I take 12+6 to really be 14+6 which exactly matches 
the 20 cycles in which you issued these. 

However, I assume the thread is issuing hexlet loads and stores, where the Hermes channel 
ends up doing double the number of octlet transactions, so I'm not sure I see exactly what 
pattern you are expecting. 

NB itself is capable of fully saturating the internal bus in Euterpe which connects it to 
the peripheral devices (Hermes channels plus DRAM) . There, there is a 32 bit bus which 
takes 4 cycles to process each octlet transaction. This is a 50% overhead over the raw 
data and at 1080MHz is therefor 2.l6GB/sec of real data. With simulated devices capable 
of absorbing this at full rate we have checked that every cycle does indeed get used. 

However, the current Hermes channel interface design does not quite sustain the peak rate 
for issuing read requests. This is a tradeoff to keep the amount of buffering under 
control to save atoms. It will sustain one read every 8 cycles (transfering a 6 byte read 
request) and one write every 16 (transfering the 14 byte write request) . (It's possible 
with the most recent design changes we have been able to plug this 2 byte gap on write 
transactions, but I need to check.) Note that for reads, the maximum sustained rate 
cannot be more than one in 10 cycles since we will be limited by the input channel 
bandwith and 

eventually starve for sequence IDs. On the input side, the channel 

will handle sustained back to back responses at the full rate (as it must, since we do 
not control when devices decide to return responses) . 

For reference, the sustained throughput of a single Calliope (in the current 
implementation) is one transaction per 16 (Calliope) clocks. This is a result of the way 
the internal bandwidth is split in a fixed pattern between Hermes and the devices and 
between reads and writes (to control the noise spectrum) . It can however support the peak 
rate on input, with the excess being buffered in a fifo. 

Simulation of real code is likely to be worthwhile, as there 
is substantial opportunity for microarchitecture interactions 
that could further limit performance. Notably, the gextract 
operation may be critical to realignment of data between DRAM 
and Calliope. 

Absolutely. We have seen major surprises in the past. 


Tim 
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From: David Bulfer [dbulfer@gaea.microunity.com] 

Sent: Tuesday, January 10, 1995 10:37 AM 

To: Tim B. Robinson' 

Cc: 'Craig Hansen'; 'abbott@MicroUnity.com'; 'agc@MicroUnity.com'; 'graham@MicroUnity.com'; 

'hessam@MicroUnity.com'; 'jt@MicroUnity.com'; 'pandora@MicroUnity.com'; 

'tony@MicroUnity.com'; 'yves@aphrodite' 
Subject: Re: Bandwidth Calculations for HighRes RGB display (was RE: Euterpe housing containing 

Calliope) 


Here's a rule of thumb on calculating pixel clocks. There are many video spec's, but 
generally, you should allocate about 35% of your time to H and V blanking. For example, 

Active area: 1280 x 1024 
Refresh: 72 Hz 

Active pixels: 1,310,720 
Blanked pixels: 458,752 
Virtual pixels: 1,769,472 
Pixel clock: 127,401,984 Hz 

In designing frame buffers, many people decouple the dot clock from the clock that writes 
the image into memory, especially with VRAM type designs. If so, you can write into 
memory at less than 100 MHz. 

Hope this helps, David 

o - 

David Bulfer (_) / (_) _- 


ema i 1 : dBu 1 f e r @M i c r oUni t y . Com 

Phone: 408-734-8590 x282 

FAX: 408-734-8136 


SnailMail: MicroUnity Systems 
Engineering, Inc . 
255 Caspian Drive 
Sunnyvale CA 94086 
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From: ken (Ken Hsieh) 

Sent: Tuesday, January 10, 1995 1:13 PM 

To: 'sysadm'; 'tbr' 

Subject: BudTool 4.3.1 Announcement 

Begin Included Message 

>From pbond@eng.pdc.com Tue Jan 10 1 1 :1 1:40 1995 

Date: Tue, 10 Jan 1995 11:10:20 +0800 

From: pbond@eng.pdc.com (Phil Bond) 

To: ken@MicroUnity.com 

Subject: BudTool 4.3.1 Announcement 

Cc: support@dm.eng.pdc.com 

X-Sun-Charset: US- ASCII 

Content-Length: 7246 


Ken, 

At your request, I am sending you a copy of the BudTool 4.3. 1 announcement: 
Begin Included Message 


Date: Fri, 1 8 Nov 94 

Dear Customer, 

We are pleased to announce the BudTool 4.3.1 release is completed and 
will begin shipping today. All BudTool customers currently under their 
initial 90-day warranty and/or covered under a maintenance agreement are 
entitled to receive this upgrade free of charge. 

Please call our customer service department at (510) 449-6881 or send 
an email tojIloyd@eng.pdc.com if you wish to receive the 4.3.1 upgrade. 
We will need you to include the following information: 

1) Your name, company name and correct Fed Ex ship-to address (with mailstop) 

2) Your phone number (in case we need to call you) 

3) The platform, architecture and OS upon which BudTool will be upgraded 

4) The type of drive or jukebox you are using 

5) The version of BudTool from which you are upgrading* 

6) The distribution media you prefer (standard shipments will be on CD-ROM) 

* Customers upgrading from BudTool 4.0.3 or 4. 1 will need to upgrade first 
to BudTool 4.2.2 before upgrading to 4.3.1. 

An overview of the new BudTool 4.3 features is provided below. 
******************************************* 

NEW BUDTOOL 4.3.1 FEATURES 

BudTool 4.3.1 offers extended media management features designed to reduce 
operator support time by up to 50%, along with other enhancements 
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summarized below. 
MEDIA MANAGEMENT 

Improved method for specifying tape rotation/expiration within the backup 

expiration policies 
Lets the system administrator specify retention time for each type of 
backup. When all backup images on a tape have expired, the tape is 
automatically returned to a logical free pool and is eligible to be 
overwritten. This eliminates complicated tape labeling schemes and 
guarantees that data will not be unexpectedly overwritten. 

Media location tracking 

A media location field has been added to the tape's database which allows 
BudTool 4.3.1 to keep track of where each tape is located. During the file 
selection process in a retrieval, BudTool 4.3. 1 identifies if a tape is 
stored in a jukebox, on-site or off-site. 

Media history 

BudTool 4.3.1 can now keep track of how old a tape is and how many times 
the media has been reused. Reports can be generated that help to decide 
when to retire a tape and can reduce media errors caused by using old 
tapes. 

Migration path to bar code labeling schemes 

For those wishing to convert from existing tape labeling schemes to bar 
code, a procedure has been documented and code developed to minimize the 
amount of labor associated with this transition. 

LARGE LIBRARY FEATURES 

Improved jukebox database initialization 
The jukebox database is automatically maintained by scanning all of the 
tapes in the jukebox. 

Automated maintenance of jukebox tape inventory sufficient for backup 
Determining if there are sufficient tapes in a jukebox to complete a 
backup and selecting which tapes to remove is a time-consuming task. 
This entire process has now been automated. BudTool 4.3. 1 determines which 
tapes can be used for backups and if there are not enough tapes, it will 
determine which are the best tapes to remove from the jukebox. It will 
also produce a list of tapes to be recycled or list how many new tapes 
are required. 

Automated re-arrangement of tapes to be exported from the library into a 
single bin-pack 

BudTool 4.3.1 will now automatically move the tapes to be exported into 
contiguous locations in the library so whole bin-packs can be removed. 
This saves labor by eliminating the need for operators to search for tapes 
and reduces the opportunity for human error. 

Automated export of volumes 

If the system administrator does not want to export bin-packs, BudTool 
4.3.1 can automatically export tapes using the entry/exit port. Exported 
tapes can be replaced by new tapes selected from a suggested import list. 

BARCODE 

Enhanced barcode support 
More extensive use of barcode labels makes it easier to keep track of 
large numbers of tapes and also reduces human error. This benefit is 
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primarily realized when used in jukeboxes with internal barcode scanners. 

Hand-held barcode scanner 
Support for a hand-held barcode reader allows users to take advantage of 
barcode labels when the tapes are not in a library. The hand-held barcode 
scanner can be used when moving or retiring tapes. It can also be used 
to list the status, location and contents of a barcoded tape. 

Delayed initialization of tape 
In jukeboxes with internal barcode scanners, the barcode is scanned and 
the tape is remembered as "blank" until used. Before the tape is used, 
its status as a blank tape is verified and the tape is labeled. This 
eliminates the time-consuming task of pre-labeling all new tapes. 

OFF-SITE BACKUPS 

Automated off-site copies 

BudTool 4.3. 1 can make a copy of all the backups required for a set of 
disaster recovery tapes. This allows you to keep one copy on-site for 
retrievals while saving another copy off-site for disaster recovery. 
The location of both tapes is maintained by BudTool 4.3. 1 . 

SECURITY 

The backup server ("goserver") can optionally use the "rexec" system call to 
start a remote backup or retrieval 

This eliminates the need for ".rhosts" entries on the clients which can 

lead to enhanced security. 

The backup server has another new option for starting backup and retrieval 
operations on clients known as "proxy" backups 

BudTool 4.3.1 can now back up machines that do not support "rsh". 

DIAGNOSTICS 

Significant improvements in the diagnostics and logging for BudTool's schedule 

daemon (btd) and the tape's database 
Problems can more easily be traced to their source and the appropriate 
remedial action taken. Much of this work will be useful for a planned 
status monitor. Now, system administrators can easily develop their own 
status monitors. 

INSTALLATION 

Enhanced BT Admin features improved tape labeling scheme, support for tape 

expiration dates and barcode labeling schemes 

BT Admin can now generate tape labels with more detail which are more 
useful. These labels are now compatible with barcode tape labels. With 
BudTool 4.3. 1, BT Admin can generate a set of schedules for each drive in 
a multi-drive library. BT Admin has also been modified to work with 
BudTool 4.3.1 media management features. 

MISCELLANEOUS 

Automatic drive cleaning 

BudTool 4.3.1 will keep track of drive usage and automatically clean the 
drives at appropriate intervals. 

ANSI Standard tape format 
A change in the BudTool 4.3.1 tape format makes it possible to maintain 
table-of-contents information without a special device driver. The new 
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format uses ANSI standard format. 


End Included Message 


End Included Message 


Exhibit CIO 


Page 111 of 356 


From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, January 10, 1995 1:46 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles, h 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/ root /s6/ lisa/ src/gnu- tools/sim/terp 

Modified Files: 
cycles . h 
Log Message: 

"hide" name of thread pointer block variable in STALL__THREAD_DELAYED 
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From: lisar (Lisa Robinson) 
Sent: Tuesday, January 10, 1995 3:43 PM 
To: 'dickson'; 'woody'; 'mws'; "billz 1 ; 'tbr'; 'jeffm' 
Subject: gettst, stashtst 

I have created 2 makefile targets, gettst and stashtst. 

They do pretty much the same as the shell scripts but they are a bit 

more flexible. 

By default, they assume that you want to get the test from your verify 
tree in $(CHIPROOT). To override just say: 
VERIFYROOT=/n/nosferatu/s2/euterpe 
or 

VERIFYROOT=/u/jeffm/chip/euterpe 

By default the test got (!) is top!evel/5woody_0. To override just say: 
TESTNAME=toplevel/test 1 J) 

So typically you would involke the make: 

gmake gettst TESTNAME=toplevel/testl_0 VERIFYROOT-/n/nosferatu/s2/euterpe 

Most tests are released and built in /u/chip/euterpe/verify so you 
could point your verify there or to /n/nosferatu/s2/euterpe/verify 

gmake stashtst to stash the test. 

Hope this helps. 

Lisa R. 


Exhibit CIO 


Page 113 of 356 


From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, January 10, 1995 8:24 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/au BOM 26.0 initiated by dickson completed @ Tue Jan 10 
18:20:12 PST 1995 with exit status 0.. chip 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, January 10, 1995 9:59 PM 

To: 'tbr' 

Cc: 'geeif 

Subject: he performance enhancement 


Tim, 

I have a working version that appears to handle conflicts properly. It is quite a bit 
bigger, but still has loading and timing problems. 

In /u/ chip/euterpe/verilog/bsrc/hc/gards/hcO -passl : 

Atoms: count atom bjt isrc pld clock 

BJT Totals: 1359 11216 24187 16836 14532 7106 

In local area with CYCLETIME=895 gards/hcO -passl : 

Atoms: count atom bjt isrc pld clock 

BJT Totals: 1496 15060 27638 24368 19632 7914 

I have some ideas to reduce size, but nothing has been thought through yet. 

Jay 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Tuesday, January 10, 1995 10:44 PM 

'gee if 

Re: New Euterpe toplevel 


> I have a new Euterpe toplevel that has Cerberus in it. This is the 
complete 

>chip . . nothing is missing . . Can you use this for more routing runs ? 

I am interested to see how many additional Cerberus nets we have to deal 
with in the most congested areas. I suspect there will be significant 
perturbations to the placement before we have a complete solution, though. 
1 1 11 pick up a copy of your latest files tomorrow if they will be stable 
until then. 


Thanks , 


Kurt 
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To: 


From: 


Sent: 


hopper (Mark Hofmann) 

Wednesday, January 11, 1995 12:38 AM 

'Lisa Robinson' 


Cc: 'tbr (Tim B. Robinson)' 
Subject: Re: planet problem 

Lisa Robinson writes: 
Just tried compiling: 

Running /n/nosferatu/s2/euterpe/tools/bin/espresso.mu... 

Running /n/nosferatu/s2/euterpe/tools/bin/espresso.mu -Dso_both... 

Running /n/nosferatu/s2/euterpe/tools/bin/espresso.mu on output of /n/nosferatu/s2/euterpe/tools/bin/espresso.mu - 
Dso_both... 

Running /n/nosferatu/s2/euterpe/tools/bin/espresso.mu -Dopo... 
Reg: tot=40 cube=17 max-AND-fanin-2 max-OR-fanin=l max-fanin=2 
Sob: tot=40 cube=24 max-AND-fanin=2 max-OR-fanin=l max-fanin=2 
SobReg: tot=40 cube=17 max-AND-fanin=2 max-OR-fanin=l max-fanin=2 
Opo: tot=40 cube=24 max-AND-fanin=2 max-OR-fanin=l max-fanin=2 

etc. 

Sorry 

I did not look at may pager. 

i can reproduce the bug. 

I need to look at it a bit more. 

i hope to have a fix for the 10am rleease. 

thanks for putting the old version back. 


-hopper 
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From: ken (Ken Hsieh) 

Sent: Wednesday, January 11, 1995 11:58 AM 

To: 'tor' 

Cc: 'sysadm' 

Subject: budtool test result 

Tim, 

I have succeed in retriving a partation by using "request history" 
in budtool. (I said "media history" on the mail of yesterday.) 
It took 3 hours and 12 minutes to restore 1.5GB of data, /s32, 
from to tapes. It's acceptable. Also, it built right ownship and 
file/directory permission. 

Ken 
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Subject: 


To: 


Cc: 


Sent: 


From: 


tbr 

Wednesday, January 11, 1995 12:02 PM 

'ken (Ken Hsieh)' 

'sysadm' 

budtool test result 


Follow Up Flag: Follow up 
Flag Status: Red 

Ken Hsieh wrote (on Wed Jan 1 1): 
Tim, 

I have succeed in retriving a partation by using "request history" 
in budtool. (I said "media history" on the mail of yesterday.) 
It took 3 hours and 12 minutes to restore 1.5GB of data, /s32, 
from to tapes. It's acceptable. Also, it built right ownship and 
file/directory permission. 

Great. Make some notes on the exact options/procedure in case someone 
else needs to run it next time. 


Tim 
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From: two (Fred Obermeier) 

Sent: Wednesday, January 1 1 , 1 995 1 :09 PM 

To: 'hardheads' 

Cc: 'fwo' 

Subject: More euterpe csyn possible errors. 


Hi, 

A recent csyn run of tbr_euterpe-passl . spivs with the partially implemented new 
Differential Input Swing check produced a few errors. The following errors should be of 
the class where differential inputs on a single gate are driven by complementary inputs 
coming from _completely different_ driver cells. 

Please take a look at the following errors and let me know if this is ok or not. I'm 
still working on debugging the Diff Input Swing check so these may or may not be false 
errors . 

Fred. 

excerpts from /u/f wo/chip . bsrc/euterpe/verilog/bsrc/SAVE/* . csyn 


error (Diff InputSwingCheck . 73 8) in file " tbr_euterpe-passl . spivs" 
drivers are non-diff or fail leaf-inp swing requirements 


Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 
cellname path: 

paired drivers 
instance path 
instance path 
cellname path 
cellname path 

paired topmost nets 
instance path 
instance path 
cellname path 
cellname path 

Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 
cellname path: 

paired drivers 
instance path; 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path; 

Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 


non-diff or fail swing check 

top . xauindxul3 2u0 . auindx_ga_l 
top .xauindxul3 2u0 . auindx_gb_n_l 
top.xbffdf4s .dO_admph 
top .xbf f df 4s . dO_andmph 

top . xauindxu02aul . auindx_ga_l 
top . xauindxu02bul . auindx_gb_n_l 
top .xbor2df 12s . q_andOpf 
top .xbor2df 12s . q_adOpf 

top . auindx_ga_l 
top . auindx_gb_n_l 
top . auindx_ga_l 
top . auindx_gb_n_l 

non-diff or fail swing check 

top . xauindxul2 8u0 . auindx_ga_2 
top . xauindxul2 8u0 . auindx_gb_n_2 
top.xbffdf4s .dO_admph 
top.xbffdf4s .do andmph 

top . xauindxu02au2 . auindx_ga_2 
top . xauindxu02bu2 . auindx_gb_n_2 
top .xbor2df 12s .q_andOpf 
top . xbor2df 6 s . q_adOpf 

top . auindx_ga_2 
top . auindx_gb_n_2 
top . auindx_ga_2 
top . auindx_gb_n_2 

non-diff or fail swing check 

top . xauindxul2 3u0 . auindx_ga_3 
top , xauindxul2 3u0 . auindx_gb_n_3 
top.xbffdf4s .dO_admph 
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cellname path: 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path; 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 

Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 
cellname path: 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 

Reason: drivers are 

diff inputs 

instance path : 
instance path: 
cellname path: 
cellname path: 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 

Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 
cellname path: 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 

Reason: drivers are 

diff inputs 

instance path: 
instance path: 
cellname path: 


top.xbffdf4s 

top . xauindxu02au3 
top . xauindxu02bu3 
top.xbor2df 8s 
top.xbor2df 8s 

top . auindx_ga_3 
top . auindx_gb_n_3 
top . auindx_ga_3 
top . auindx_gb_n_3 

non-diff or fail swing check 

top . xauindxull7u0 
top . xauindxull7u0 
top.xbf fdf4s 
top.xbf fdf4s 

top . xauindxu02au4 
top . xauindxu02bu4 
top.xbor2df 8s 
top . xbor2df 6 s 

top . auindx_ga_4 
top . auindx_gb_n_4 
top . auindx_ga_4 
top . auindx_gb_n_4 

non-diff or fail swing check 

top .xmcu02msl3u0 .mc_u02_opl_5 
top.xmcu02msl3u0 . mc_u02_op2_n__5 
top.xbf fdf 24s . dO_admph 
top.xbf fdf 24s .dO_andmph 

top . xmcu02opcoduS . mc_u02_opl_5 
top . xmcu02opcd5u0 . mc_u02_op2_n_5 
top .xbf fbdf 16s . q_adOpf 
top .xbf fbdf 16s . q_andOpf 

top .mc_u02_opl_5 
top . mc_uO 2 _op 2 _n_5 
top .mc_u02_opl_5 
top . mc_uO 2_op2_n_5 

non-diff or fail swing check 

top . xif euif phb3u0 . if e_if povrlyr2_12 
top .xif euifphb3u0 . if e_pclob2_12 
top . xbf f dh4 s . dO_admph 

t op . xb f f dh4 s . do _andmph 

top . xif euif povrlyb2u0 . if e_if povrlyr2 
top . xif eupclob2ul0 . if e_pclob2_12 
top.xbor2df4s . q_andOpf 

top. xbf fdf 4s .q_adOpf 

top. if e_ifpovrlyr2_12 
top . if e_pclob2_12 
top . if e_ifpovrlyr2_12 
top . if e_pclob2_12 

non-diff or fail swing check 

top.xifeuifphb3ul . if e_if povrlyr2_13 
top . xif euif phb3ul . if e_pclob2_13 
top . xbf f dh4 s . d 0_admph 


. dO_andmph 

. auindx_ga_3 
. auindx_gb_n_3 
. q_andOpf 
. q_adOpf 


. auindx_ga_4 
. auindx_gb_n_4 
.dO_admph 
.dO_andmph 

. auindx_ga_4 
. auindx_gb_n_4 
.q_andOpf 
. q_adOpf 
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cellname path: 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 

Reason: drivers are 

diff inputs 
instance path 
instance path 
cellname path 
cellname path 

paired drivers 
instance path: 
instance path: 
cellname path: 
cellname path: 

paired topmost nets 
instance path: 
instance path: 
cellname path: 
cellname path: 


top.xbf fdh4s 


. dO_andmph 


top . xif euif povrlyb2ul . if e_if povrlyr2_13 
top . xif eupclob2ull . if e_pclob2_13 
top .xbor2df 4s .q_andOpf 
top.xbffdf4s ,q_adOpf 

top . if e_ifpovrlyr2_13 
top . if e_pclob2_13 
top . if e_if povrlyr2 13 
top . if e_pclob2_13 

non-diff or fail swing check 

top . xif euif phb3u2 . if e_if povrlyr2_14 
top . xif euif phb3u2 . if e_pclob2_14 
top . xbf f dh4s . dO_admph 

top . xbf f dh4s . dO_andmph 

top .xif euif povrlyb2u2 . if e_ifpovrlyr2_14 
top . xif eupclob2ul2 . if e_pclob2_14 
top.xbor2df 4s . q_andOpf 

top.xbffdf4s .q_adOpf 

top. ife_ifpovrlyr2_14 
top . if e_pclob2_14 
top. ife_ifpovrlyr2_14 
top . if e j>clob2_14 


Exhibit CIO 


Page 122 of 356 


From: mws (Mark Semmelmeyer) 

Sent: Wednesday, January 11 , 1 995 1 :29 PM 

To: 'two' 

Cc: 'hardheads' 

Subject: Re: More euterpe csyn possible errors. 


The ife errors were real and are fixed in ife.V 1.37. 

They would have eventually been found by functional tests for ICache and/or trying more 
varied code branch target addresses (hopefully) . 
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Sent: 

To: 

Cc: 


Subject: 


From: 


wingard (Drew Wingard) 

Wednesday, January 11, 1995 2:29 PM 

'fwo'; 'rows' 

'hardheads' 

Re: More euterpe csyn possible errors. 


Mws writes : 

> The ife errors were real and are fixed in ife.V 1.37. 

> They would have eventually been found by functional tests for ICache 

> and/or trying more varied code branch target addresses (hopefully) . 

I don't have the ife errors in front of me, but I wonder how functional testing would 
catch them. 

The perceived importance of this new 'phase' of differential swing checks is due to our 
understanding that existing functional models ignore the 'complemented' half of all 
differential inputs. If this is true, then functional test are unable to detect problems 
resulting from connecting differential inputs to the outputs of cells which generate 
different logical signals . 

For instance, connecting the differential data inputs of a ff to busa_adOph and 
busb_andOph is electrically incorrect (makes a great 

A A 

metastability test!) but would pass functional testing that ignored the complemented input 
as long as the intended function was to delay busa by one clock cycle. 

This is a check that we thought csyn was performing all along. Oops. 

I believe that Fred is going to test Calliope once he has the check fully implemented. 

Of course, folks who make heavy use of the Verilog macros (D ( ) , etc) are not likely to 
have problems like this. A situation where we are vulnerable is when someone copies a 
block of Verilog which calls out the inputs separately and then changes the output and 
true input names, but overlooks the complemented inputs. 


Drew 
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Subject: 


Sent: 

To: 

Cc: 


From: 


mws (Mark Semmelmeyer) 
Wednesday, January 11, 1995 2:36 PM 
Two'; 'wingard' 
'hardheads' 

Re: More euterpe csyn possible errors. 


> From wingard Wed Jan 11 12:29:00 1995 
> 

> Mws writes : 

> > The ife errors were real and are fixed in ife.V 1.37. 

> > They would have eventually been found by functional tests for ICache 

> > and/or trying more varied code branch target addresses (hopefully) . 
> 

> I don't have the ife errors in front of me, but I wonder how 

> functional testing would catch them. 

Your explanation of misconnected differential inputs intended to be differential is 
correct. My particular case is observable functionally because the 2 inputs were supposed 
to be ORed together, not just 1 of them staged. Because an orff2 and ff have the same 
number and types of ports, normal port mismatch checks don't catch it like it would for a 
differential OR or a wider fanin OR. 
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From: 


tbr 


To: 

Subject: 


Sent: 


Wednesday, January 11, 1995 3:50 PM 
'lisar'; 'jeffm' 

forwarded message from Mark Semmelmeyer 


Follow Up Flag: Follow up 
Flag Status: Red 

Would be worth understanding what it would have taken to see this. 

Start of forwarded message 

Return-Path: <mws> 

Received: from clytemnestra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA22413; Wed, 11 Jan 95 1 1:33:10 PST 
Received: from localhost by clytemnestra.microunity.com (8.6.4/muse-sw.3) 

id LAA01042; Wed, 1 1 Jan 1995 1 1 :29:07 -0800 
Message-Id: <199501 1 1 1 929.LAA01042@clytemnestra.microunity.com> 
From: mws (Mark Semmelmeyer) 
To: two 
Cc: hardheads 

Subject: Re: More euterpe csyn possible errors. 
Date: Wed, 11 Jan 1995 11:29:07 -0800 

The ife errors were real and are fixed in ife.V 1.37. 
They would have eventually been found by functional 
tests for ICache and/or trying more varied code branch 
target addresses (hopefully). 
End of forwarded message 
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From: doi (Derek Iverson) 

Sent: Wednesday, January 11, 1995 6:30 PM 

To: 'sandeep'; 'guarino'; 'gmo'; 'jeffm'; 'wayne'; 'doi'; 'jerry'; 'iimura' 

Cc: 'hestia' 

Subject: Software Bringup Meeting Minutes - January 1 1 , 1995 


Software Bringup Meeting 


January 11, 1995 
Next Meeting: January 18 at 10:00 am. 


Attendees: jeffm, guarino, gmo, sandepp, doi 
New Action Items 


Item: Rerun dcacheharder test and get cycle count results. 
Who : doi 

Status: [01/11] New. 

The previous run of dcacheharder didn't have the proper configuration 
files . 

Item: More investigation on CBI and workstation interface issues. 
Who: guarino, wayne 

Need to get further details on the hardware modi fictions that 
wayne discusses at a previous meeting that would allow for 
the cerberus clock to be free -running as long as there was 
no activity on the bus (wayne) . 

Lorreta is going to investigate the possibility of figuring out 
how to interface to the parallel port hardware on the sgi . 


Review of Action Items 


Item: Implement parallel port device driver for Linux on PC. 
Who: jerry, doi 

Status: [12/14] In progress. 


Item: Define and implement a snapshot environment for the HW and SW 

simulators . 
Who: jeffm, gmo 
Status: [11/30] In progress 

The IKOS simulator isn't as easy to load and restore state as we 
had previously thought. 

Jeff is finishing his list of high-level thoughts on how we can 
achieve a snap-shot environment. 


Item: Continue trying to find either source code for parallel drivers 

or descriptions of hardware so we can write out own. 
Who: gmo sgi machines 
Who: doi sun machines 

Status: [11/2 3] progress continues (although not much) . 
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The never ending item 

Derek will call Avcom to get more information about Sun drivers. 

Item: Build scripting/UI capabilities above gdb for regression tests. 
Who : doi 

Status: on hold until the the boot, gdb boot stub, and virtual devices 

are complete, (estimated start date of 1/10) 

Start date may be the end of this week (01/13) . 

Item: Create performance test plan 

Who: jeffm, guarino 

Status: [11/30] In progress. 

We continue to run tests to help us compare terp vrs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Item: Add Unix- like tests to software acceptance tests. 
Who: iimura 

Status: [11/30] In progress. 

Any day now. . . 


Item: Simulator needs to understand "reset 1 
Who : gmo 

Status: [11/30] In progress. Target finish of 1/20. 


Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep / gmo 

Status: in progress {delayed until 1/10 from original target of 12/23) 

A couple days delay... Mostly on track. 


Completed Items 


Item: Get cycle counts of kernel tests to jeffm 

Who : guarino 

Status: [12/14] Done. 


Test Status 


synctest has run. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Wednesday, January 11, 1995 7:05 PM 
'dbulfer' 

'pandora'; 'graham' 
Pandora clock 


Dave - 

The problem to be solved is the clocking arrangement of a Pandora system that carries a 
Calliope module {which must necessarily carry its own low- jitter 1080MHz clock for RF 
applications, and to which is locked all digital logic in the Hestia design) . 

Is it feasible - in those applications - to omit or disconnect the new 54MHz Euterpe clock 
that you are building for an all-digital application, and feed a 54MHz clock from a 
Calliope module across the backplane? 

Regards , Graham . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


dbulfer (David Bulfer) 

Wednesday, January 11, 1995 7:53 PM 

'Graham Y. Mostyn' 

'pandora'; 'graham (Graham Y. Mostyn)' 
Re: Pandora clock 


> Dave - 

> The problem to be solved is the clocking arrangement of a Pandora 

> system that carries a Calliope module (which must necessarily carry 

> its own low- jitter 1080MHz clock for RF applications, and to which is 

> locked all digital logic in the Hestia design) . 
> 

> Is it feasible - in those applications - to omit or disconnect the new 

> 54MHz Euterpe clock that you are building for an all-digital 

> application, and feed a 54MHz clock from a Calliope module across the 

> backplane? 
> 

> Regards, Graham. 


we plan on having a clock distribution system that will broadcast identical copies of the 
clock to all modules (where is may or may not be used) . A good solution is to have the 
Calliope module connect its clock over a shielded- twistd pair cable to clock distribution 
board. 

This would permit the maximum flexibility of physical location for Calliope while 
maintaining signal integrity and not burdening the connectors. 


David 
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From: 


tbr 


To: 


Subject: 


Sent: 


Wednesday, January 11, 1995 7:58 PM 
'lisar' 

vhdl problem 


Follow Up Flag: Follow up 
Flag Status: Red 

We found it. The original was: 

entity i_euterpe_wrap is 
port( 

poko in; std_logic; 

rdata out: std_logic_vector (63 downto 0); 

sdclockO_abm out: std_logic; 

sdc_abm out: std_logic_vector (4 downto 0); 

sda_abm out: std_logic_vector (12 downto 0); 

sdd_abm inout: std_logic_vectore (3 1 downto 0) 

); 

end ieuterpejwrap; 

It should be: 

entity i_euterpe_wrap is 
port( 

poko : in std_logic; 

rdata : out std_logic_vector (63 downto 0); 

sdclocku_abm : out std logic; 

sdcabm : out std_logic_vector (4 downto 0); 

sda abm : out std _Jogic_vector (12 downto 0); 

sdd_abm : inout std Jogic_vector (3 1 downto 0) 

); 

end i_euterpe_wrap; 

For some reason it compiled it with nothing. According to Pat, the 
default is in, so that should not account for it. However, he says that 
if we bring it up to the vhdl level, and connect a net to it, it will 
put in a driver that will clash with the driver from the stimulus. 
So I think we need to remove poko from the wrapper interface. 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


fwo (Fred Obermeier) 

Wednesday, January 11, 1995 8:07 PM 

'hardheads' 

'fwo' 

Re: More euterpe csyn possible errors. 


Drew wrote : 

> I believe that Fred is going to test Calliope once he has the check 
fully 

> implemented. 

I couldn't wait to see if there might be a problem with Calliope. 

The current limited version of the differential input swing check didn't find any problem 
with the snap-shot version: 

/n/auspex/s30/calliope/verilog/src/small_calliope-iter. spivs 
Only the error messages relate to the Old Style phase checks as reported by previous runs. 
I'll rerun again once this test is completely implemented. 


Fred. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Wednesday, January 11, 1995 8:17 PM 
'graham (Graham Y. Mostyn)' 
'dbulfer'; 'graham'; 'pandora' 
Pandora clock 


Graham Y. Mostyn wrote (on Wed Jan 11) : 
Dave - 

The problem to be solved is the clocking arrangement of a Pandora 
system that carries a Calliope module (which must necessarily carry its 
own low- jitter 1080MHz clock for RF applications, and to which is 
locked all digital logic in the Hestia design) . 

Is it feasible - in those applications - to omit or disconnect the 
new 54MHz Euterpe clock that you are building for an all -digital 
application, and feed a 54MHz clock from a Calliope module across 
the backplane? 

Yes, the 54 MHz source would be on the "herrainator" that you would remove to attach the 
calliope module to hermes . 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Wednesday, January 11, 1995 8:19 PM 
'fwo (Fred Obermeier)' 
'fwo'; 'hardheads' 

Re: More euterpe csyn possible errors. 


Follow Up Flag: Follow up 
Flag Status: Red 

Fred Obermeier wrote (on Wed Jan 1 1): 
Drew wrote: 

> I believe that Fred is going to test Calliope once he has the check fully 

> implemented. 

I couldn't wait to see if there might be a problem with Calliope. 
The current limited version of the differential input swing check 
didn't find any problem with the snap-shot version: 
/n/auspex/s30/calliope/verilog/src/small_calliope-iter.splvs 
Only the error messages relate to the Old Style phase checks as 
reported by previous runs. I'll rerun again once this test is 
completely implemented. 


Phew! 


Thanks 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 11, 1995 8:19 PM 

'two (Fred Obermeier)' 

'two'; 'hardheads' 

Re: More euterpe csyn possible errors. 


Fred Obermeier wrote (on Wed Jan 11) : 
Drew wrote : 

> I believe that Fred is going to test Calliope once he has the check fully 

> implemented. 

I couldn't wait to see if there might be a problem with Calliope. 
The current limited version of the differential input swing check 
didn't find any problem with the snap-shot version: 

/n/auspex/s3 0/calliope/verilog/src/small_calliope-iter. spivs 
Only the error messages relate to the Old Style phase checks as 
reported by previous runs. I'll rerun again once this test is 
completely implemented. 


Phew! 


Thanks 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Eich [tbe@MicroUnjty.com] 
Wednesday, January 11, 1995 9:55 PM 
Tim B. Robinson* 

'graham@MicroUnity.com'; 'jt@MicroUnity.com'; 'pandora@MicroUnity.com' 
Re: Analog modul form factor 


>I thought of a possibel soution to having a larger form factor for the 
>analog modules. Suppose we mounter the analog board horizonatally and 
>use a flexible cable connection to connect to the hermes connector on 
>the backplane. This would allow a board of whatever width you needed 
>with full access at the rear/front panel for connectors. 
>When this module is not required, the same hermes slot would of course 
>still accept a small form factor (digital?) module. 


I think I understand what you mean here, but have a concern with airflow management that 
I'll have to describe with a drawing. I'll try to stop by. 

>I'm no good at doing those cute ascii diagrams some people like to put 
>in email, so if the above makes no sense please catch me near a white 
>board. 


This afternoon met with Graham, Jean- Yves , Tony and Grant to go over analog sizing and 
packaging issues, and concluded that there is probably adequate pcb area within a Euterpe 
sized module given Euterpe heat sink size vs. 

Calliope heat sink size. I am working on a module layout for completion by week's end, 
and will review with appropriate parties before then. 


> 


>Tim 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 089 
(408)734-8100, (408)734-813 6 fax 


tbe@microunity . com 
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From: 
Sent: 


Wednesday, January 11, 1995 10:24 PM 
'Tom Eich' 

'graham'; 'jt'; 'pandora' 

Re: Analog modul form factor 


tbr 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Wed Jan 11): 

>I thought of a possibel soution to having a larger form factor for the 
>analog modules. Suppose we mounter the analog board horizonatally 
>and use a flexible cable connection to connect to the hermes connector 
>on the backplane. This would allow a board of whatever width you 
>needed with full access at the rear/front panel for connectors, 
>When this module is not required, the same hermes slot would of course 
>still accept a small form factor (digital?) module. 


I think I understand what you mean here, but have a concern with airflow 
management that I'll have to describe with a drawing. I'll try to stop by. 

Never said it would be easy! It is a problem because the calliope 
would have to be on the big board to avoid the the connector 
transitions that make a multi-board small form factor soultion 
unattractive. If that were no problem, annother arrangement would 
have a rigid connection to the backplane which could itself carry the 
calliope with similar air manage\ment to normal modules. 

>I'm no good at doing those cute ascii diagrams some people like to put 
>in email, so if the above makes no sense please catch me near a white 
>board. 


This afternoon met with Graham, Jean-Yves, Tony and Grant to go over analog 
sizing and packaging issues, and concluded that there is probably adequate 
pcb area within a Euterpe sized module given Euterpe heat sink size vs. 
Calliope heat sink size. I am working on a module layout for completion by 
week's end, and will review with appropriate parties before then. 

OK. If we can fit it that way it's clearly preferable to my 
suggestion. 


> 


> 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, Januaiy 11, 1995 10:24 PM 

Tom Eich' 

'graham'; 'jt'; 'pandora' 

Re: Analog modul form factor 


Tom Eich wrote (on Wed Jan 11) : 

>I thought of a possibel soution to having a larger form factor for the 
>analog modules. Suppose we mounter the analog board horizonatally 
>and use a flexible cable connection to connect to the hermes connector 
>on the backplane. This would allow a board of whatever width you 
>needed with full access at the rear/front panel for connectors. 
>When this module is not required, the same hermes slot would of course 
>still accept a small form factor (digital?) module. 


I think I understand what you mean here, but have a concern with airflow 
management that I'll have to describe with a drawing. I'll try to stop by. 

Never said it would be easy! It is a problem because the calliope would have to be on the 
big board to avoid the the connector transitions that make a multi-board small form factor 
soultion unattractive. If that were no problem, annother arrangement would have a rigid 
connection to the backplane which could itself carry the calliope with similar air manage 
\ment to normal modules . 

>I'm no good at doing those cute ascii diagrams some people like to put 
>in email, so if the above makes no sense please catch me near a white 
> board . 


This afternoon met with Graham, Jean- Yves, Tony and Grant to go over analog 
sizing and packaging issues, and concluded that there is probably adequate 
pcb area within a Euterpe sized module given Euterpe heat sink size vs. 
Calliope heat sink size. I am working on a module layout for completion by 
week's end, and will review with appropriate parties before then. 

OK. If we can fit it that way it's clearly preferable to my suggestion. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Thursday, January 12, 1995 12:20 AM 

'billz (Bill Zuravleff)'; 'geert (Geert Rosseel)' 

'vant' 

nb status 


Hi, 


I'm not sure what's happened but the NB placement that I've checked in iterates 10 times 
and does not make timing. I _thought_ that I had a placement that iterated 7 times and did 
converge. Unfortunately, I lost the source of this placement in the auspex crash, but I 
also thought that I had re-created it successfully. 

At any rate, the version that is now checked in runs the same in /u/chip as my home area 
and does not converge. I will try to look at the results but please feel free to look at 
them as well . 

In my area the makefile output is 

-hopper /chip/euterpe/verilog/bsrc/nb/out 

for /u/chip it is: 

/n/tmp/chiplog/hopper . tomato . 19211 . euterpe-verilog-bsrc-nb 

-thanks , 
hopper 


thanks , 
mark hofmann 
hopper@microunity . com 
408 734 8100 
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From: geert (Geert Rosseel) 

Sent: Thursday, January 12, 1995 10:24 AM 

To: W 

Subject: Euterpe top level 
Hi Tim, 

I build a toplevel euterpe with cerberus in it . I will do an 
update today and build the next one if I am up to it. 

Geert 
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To: 


Sent: 


From: 


geert (Geert Rosseel) 

Thursday, January 12, 1995 10:30 AM 

'torn* 


Cc: lisar'; 'tbr'; 'wingard' 
Subject: Two new databases 

Hi Tom, 

Can you install two new databases : 

1 . CMOS-proteus : common database for CMOS design style chips 

2. CMOS-euterpe database for CMOS euterpe 
You are free to choose the names as you wish .. 

We've decided to start a new proteus for the CMOS stuff.... 

I probably will not be in this week, but can you and Drew further 
discuss the issue of how to deal with different processes in the 
schematics ? 


Thank's 


Geert 


Exhibit CIO 


Page 141 of 356 


From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Thursday, January 12, 1995 10:48 AM 

'geert' 

Re: Euterpe 


> Hi Kurt, did you get the latest Euterpe. I'd like to build the next one. 


I didn't pick it up; other things came up yesterday with mask vendors and 
gardswarts. We did continue to study the prior placement, however, and 
extract more information from it. 

Go ahead and commence the build of the next one and I'll pick it up once 
the source files are ready. 

I believe mws, billz, dickson & I plan to have a follow-up meeting with tbr 
today to review the results of their study; it looks like some fairly 
significant changes in placement are warranted, and possibly a baseplate/ 
floorplan change. If you make it in today, this is something you should 
definitely be involved in. 


> 


>Geert 


- Kurt 
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From: 


tbr 


Sent: 
To: 

Subject: 


Thursday, January 12, 1995 11:13 AM 
'geert (Geert Rosseel)' 
Euterpe top level 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Thu Jan 12): 


Hi Tim, 

I build a toplevel euterpe with cerberus in it . I will do an 
update today and build the next one if I am up to it. 

OK. Billz has determined that we should be able to fix the left side 
routing problem if we can move LTLB down. We seem to have a lot of 
space around UU. Is that realistic or had you powered it down some 
way in the last run? 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr (Tim B. Robinson) 

Thursday, January 12, 1995 11:13 AM 

'geert (Geert Rosseel)' 

Euterpe top level 


Geert Rosseel wrote (on Thu Jan 12} : 


Hi Tim, 

I build a toplevel euterpe with cerberus in it . I will do an 
update today and build the next one if I am up to it. 

OK. Billz has determined that we should be able to fix the left side routing problem if 
we can move LTLB down. We seem to have a lot of space around UU. Is that realistic or 
had you powered it down some way in the last run? 


Tim 
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From: stick {Bruce Bateman) 

Sent: Thursday, January 12, 1995 12:25 PM 

To: 'hardheads'; 'mouss' 

Cc: 'stick' 

Subject: 1995 ISSCC 


Well, its that time of year again. The deadline for the "cheaper" 

registration is Feb 1, so we need to put together a list of who's interested in attending. 
Same as last year, I volunteer to be the "gatherer" of names, so if you're interested, 
email me and include your IEEE number if you're a member. I'll complile the the list and 
see if we can put together a group PO for the registrations. 

Please note that both a Short Course and Tutorials are being offered this year, so if you 
are interested in either or both of these, please indicate in your email. 

I have a stack of advanced programs in my office for anyone who's interested and hasn't 
received one in the mail. 


A few highlights 


Plenary : 

Digital -Storage Media in the Digital -Highway Era 
Toshiyuki Yaraada - Sony 

(Note - Sony will be giving a demo of their digital VCR) 

The Making of the PowerPC 
Raymond Dupont - IBM 

Gigachips: Deliver Affordable Multimedia for Work and Play Via 
Broadband Netword and the Set -Top Box 
Pallab Chatter jee - TI 


uP 1 s : 


13 3MHz 64b Four- issue CMOS uP {from Motorola - next powerPC} 

0 . 6u BiCMOS Processor {from Intel - P6} 

64b uP with Multimedia Support {from Sun} 

3 00MHz Quad- Issue CMOS RISC {from DEC - next Alpha} 


Video Signal Proc. : 

An MPEG-1 A/V Decoder with 
Run -Length- Compressed 
Antialiased Video Overlays 

A Helf-Pel Precision MPEG-2 
Motion- Estimation Processor 
with Concurrent Three -Vector 
Search 


{from C-Cube} 


{from Mitsubishi} 


A Single- Chip Videophone Video {from SGS- Thomson} 
Encoder /Decoder 


Memories : 

An Experimental 22 0MHz 1Gb DRAM {from Hitachi} 

A 1Gb DRAM for File Applications {from NEC} 

A 10Mb 3D Frame-Buffer Memory {from Mitsubishi} 
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z- Compare and alpha- Blend 
Units 


Evening Panels: 

Silicon Foundries: Partners, Suppliers or Competitors 
The Digital Highway: The Off Ramp to the Home 
Analog BiCMOS : Luxury or Necessity? 

In-House CAD vs. Vendor CAD for High-Perf Processors 
Single-Chip Integration vs. Multichip Modules 

Short Course: 

The Role of ATM on the Digital Highway 

Tutorials : 

Intro to Over sampled Data Conversion 
Clocking Techniques in uP's 
Overview of Radio Comm/RF circuits 
Embedded Cache Memory Design 
Solid-State Imaging 

Sig-Proc in magnetic hard- disk drives. 

Anyway, thats the scoop. Don't wait to email me your interest 'cause Feb. 1 is just a 
couple of weeks away. 

BB 
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Subject: 


Sent: 

To: 

Cc: 


From: 


mudge (john mudge) 

Thursday, January 12, 1995 2:25 PM 

'cadettes'; 'albers'; 'paulp' 

'tomho'; 'michael'; 'geert'; 'tbr'; 'mudge' 

Rules changes 


Each, 

It ' s my understanding that the recent rules 1 changes are being implemented in euterpe . I 
am thinking particularly of the collector plug change. 

We have a number of test patterns in the scribe channel and would like to implement the 
new rules so that the test patterns reflect what ' s on the product die . 

I think that we can probably handle the changes ourselves (Tom, myself and Chris) but how 
long do we have to do it and are we permitted to do it? 


j ohnnymudge 
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From: albers (Daniel Albers) 

Sent: Thursday, January 12, 1995 2:49 PM 

To: 'John mudge' 

Cc: 'cadettes'; 'paulp (Paul Poenisch)'; 'tomho (Tom Ho)'; 'michael (Chris Michael)'; 'geert (Geert 

Rosseel)'; 'tbr (Tim B. Robinson)'; 'mudge (john mudge)' 
Subject: Re: Rules changes 


> the words of j ohn mudge : 
> 

> Each, 

> It ' s my understanding that the recent rules 1 changes are being 

> implemented in euterpe. I am thinking particularly of the collector 

> plug change. 

> We have a number of test patterns in the scribe channel and would like 

> to implement the new rules so that the test patterns reflect what's on 

> the product die. 

> I think that we can probably handle the changes ourselves (Tom, myself 

> and Chris) but how long do we have to do it and are we permitted to do 

> it? 


Two schedule details to be aware of with regards to editing the cells: 

1) Frame rebuild takes about 1 day after the etest cells have 
been released. 

I have to rebuild the frame because we split the etest cells down 

the middle in parameter scribes and there is some synthesis which 
takes place to generate scribe extenders which protect against 
mis-step slivers. I would not feel confortable about editing the 
etest cells and not regenerating the frame. 

2) I will be on vacation 1/18 (next Wed) through 1/27 (1.5 weeks) . 


So if the schedule permits it, I see no reason not to edit/drc the cells. 
Dan 

Daniel Albers albers@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 

It can be made into a monster if we all pull together as a team. . . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


paulp (Paul Poenisch) 

Thursday, January 12, 1995 3:15 PM 

'John mudge' 

'tomho (Tom Ho)'; 'michael (Chris Michael)'; 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 
'cadettes' 

Re: Rules changes 


> 


> Each, 

> It's ray understanding that the recent rules' changes are being 

> implemented in euterpe. I am thinking particularly of the collector 

> plug change . 

> We have a number of test patterns in the scribe channel and would like 

> to implement the new rules so that the test patterns reflect what's on 

> the product die . 

> I think that we can probably handle the changes ourselves (Tom, myself 

> and Chris) but how long do we have to do it and are we permitted to do 

> it? 
> 

> j ohnnymudge 


I agree that the changes should be made. If they are not the scribeline will have to go 
through a different fracture flow or the collector plugs and well taps will not work at 
all. Additionally unless you've done something very strange in the test structures the 
changes should be quite straight forward and quick. 


> 


Johnny , 


Paul . 
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Sent: 

To: 

Cc: 


Subject: 


From: 


torn (Tom Laidig) 

Thursday, January 12, 1995 4:51 PM 
'Paul Poenisch' 

' mudge@acteon.microunity.com'; 'tomho (Tom Ho)'; 'michael (Chris Michael)'; 'geert (Geert 
Rosseel)'; 'tbr (Tim B. Robinson)'; 'cadettes' 
Re: Rules changes 


Paul Poenisch writes: 


> Each, 

> It 1 s my understanding that the recent rules 1 changes are being 

> implemented in euterpe. I am thinking particularly of the collector 

> plug change. 

> We have a number of test patterns in the scribe channel and would 

> like to implement the new rules so that the test patterns reflect 

> what ' s on the product die . 

> I think that we can probably handle the changes ourselves (Tom, 

> myself and Chris) but how long do we have to do it and are we 

> permitted to do it? 
> 

> j ohnnymudge 


I agree that the changes should be made. If they are not the 
scribeline 
will 

[have to go through a different fracture flow or the collector plugs and 
well 

| taps will not work at all. Additionally unless you've done something 
very 

| strange in the test structures the changes should be quite straight 
forward and 
| quick. 

The well tie changes shouldn't be terribly hard to make, I think, since only a few layouts 
actually contain well ties. Scanning proteus/ compass /frame, I find only the following 
cells that contain geometry on the collector-plug layer: 

bicmos_f illl2x28al 
bicmos_f illl2x2 8v2 
bpol_fill8x28al 
bpol_fill8x28v2 
cmos__f ill6xl2al 

I've been working over the cells in proteus/compass/layouts, and am nearly finished 
upgrading them to the new rules ( I think - - I haven 1 1 run any through Dave ' s new beta DRC 
flow yet) . 


Tom L 
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From: geert (Geert Rosseel) 

Sent: Thursday, January 12, 1995 2:45 PM 

To: 'tbr' 

Cc: 'billz'; 'dickson'; 'hopper'; 'mws'; 'wampler' 
Subject: Re: Euterpe top level 

I believe there i sgoing to be extra space around uu. 

Also, and thi sdepends a lot on what hcO is going to d, but 
assuming that hcO is not chagning too much, I believe there 
might be a gap between nb and at to squeeze a part of It in. 

We have shifted nb to the left with about 60 atoms and Hopper/Billz 
have done a great job straightening out the edges. I believe that there might be 
enough room there to put It in. That, of course, will depend a lot on what hcO 
wiil do. The last I heard from Jay was that it was growing a lot. 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Thursday, January 12, 1995 6:55 PM 
'geert (Geert Rosseel)' 
'billz'; 'dickson'; 'hopper'; 'mws'; 'warn pier' 
Re: Euterpe top level 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Thu Jan 12): 

I believe there i sgoing to be extra space around uu. 

Also, and thi sdepends a lot on what hcO is going to d, but 
assuming that hcO is not chagning too much, I believe there 
might be a gap between nb and at to squeeze a part of It in. 

We have shifted nb to the left with about 60 atoms and Hopper/Billz 
have done a great job straightening out the edges. I believe that there might be 
enough room there to put It in. That, of course, will depend a lot on what hcO 
wiil do. The last I heard from Jay was that it was growing a lot. 


It grew more than we were expecting, but woody thinks he can shrink it 
back a fair bit by reorganizing an overloaded PLA. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, January 12, 1995 6:55 PM 

'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'mws'; 'wampler' 

Re: Euterpe top level 


Geert Rosseel wrote (on Thu Jan 12) : 

I believe there i sgoing to be extra space around uu. 

Also, and thi sdepends a lot on what hcO is going to d, but 
assuming that hcO is not chagning too much, I believe there 
might be a gap between nb and at to squeeze a part of It in. 

We have shifted nb to the left with about 60 atoms and Hopper/Billz 
have done a great job straightening out the edges. I believe that there might be 
enough room there to put It in. That, of course, will depend a lot on what hcO 
wiil do. The last I heard from Jay was that it was growing a lot. 


It grew more than we were expecting, but woody thinks he can shrink it back a fair bit by 
reorganizing an overloaded PLA. 


Tim 


Exhibit CIO 


Page 153 of 3 


Subject: 


Sent: 
To: 

Cc: 


From: 


Tom Eich [tbe@MicroUnity.com] 

Friday, January 13, 1995 12:45 AM 

'boxers@MicroUnity.com'; 'dbulfer@MicroUnity.com' 

'pandora@MicroUnity.com' 

Pandora meeting minutes/actions, 1/12 


Actions and status are as follows: 

>l) Noel to prepare a power spreadsheet with current by voltage per 

>module 

or 

>>lowest separable unit. 
Status: in progress. 

>2) Noel to determine availability of single and multiple output 
Cukconverters 

» (syncronous rectifiers) with adequate output for both Euterpe and 
> > Mnemo 
>bricks . 

Decision taken to pursue a single integrated multiple output power supply for all modules 
(with the possible exception of the mixed signal module) as first course. All other dc-dc 
actions from previous meeting are on hold as a result. 

Action: Philip and Noel to prepare power supply trade matrix. 
Action: Noel to survey vendors and id candidate supplies. 


>4) Noel and Vijay to id all signal and signal ground I/O lines for both 
the 

>> Euterpe and Mnemo bricks >snip< 

Status: in progress; signal and signal ground requirements identified. 

Action: Determine power requirements (ref . 1) above) and candidate power connectors and 
bus bars . 

>5) Noel to identify de- coupling cap requirements and tbe to include in 
area 

>>calculations and layouts. 
Action: in progress. 

>6) Noel to investigate with tbr, dbulfer, and geert the implications of 
>>unsynchronized or disorderly power- up of the various bricks in 
>> Pandora, 
and 

>>specify p/s and system level requirements accordingly. 
Moot with single power supply. 

>7) Herman is trading aluminum vs. copper for the mnemo heatsink. Die 
attach 

>is >assumed to be the same as for the current Euterpe. Issue with 
aluminum 

>wrt low >impedance return path from back of die to pcb. 

Action: Herman and tbe to trade off cost of plating aluminum vs copper and assess other 
impacts {weight, thermal performance) . 

>S) Herman to trade-off integral Mnemo fan vs. external system 
>blower <s) ; 


>snip< 
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tbe 

>>and jt to support with layout concepts. 

Decision taken to pursue system level blowers for Mnemo modules and PCI cards as a first 
course, due to noise, size and power impact of individual module fans. 

>9) David is preparing a BOM for the clock card; for now he sez to 

>assume 

a 

>>single crystal oscillator with 6 ECL parts at 1 Watt each. 

The system clock has moved to the PCI/Hermes bridge module. 

>10) PCI/Hermes bridge module is not well defined as yet; David is 
> working 
on a 

>>preliminary BOM; he promises multiple voltage requirements (3.3, 5 and 
>12Vdc) . 

This modules form factor and components /interconnect were discussed. Two approaches were 
sketched: a) A dual backplane (one for PCI, one for Hermes, orthogonally positioned) with 
the bridge card having connection to both, and b) a single module between the first PCI 
card and the Euterpe module with interconnects for PCI, ISA and Hermes to a single system 
backplane . 

Action: jt and tbe to lay out and iterate to determine optimal configuration. 

Discussion of contents of this module yielded following issues: 

What system temperature sensing/thermal management is planned relative to each airmover 
and heat source? Need to determine level of sensing appropriate to disparate modules and 
heat source. Discussed having system monitoring components on bridge module. 

Question: Does Mnemosthene have on chip temperature sensing as do Euterpe and Calliope? 

Action: Noel and David to determine location and type of thermal protection in Pandora, 


Discussed the PCI card containing the Mnemo and external Hermes port (for hestia, etc) . 
If this card conforms to the PCI mechanical standard, then this Mnemo will need a 
different heat sink than planned for the modules. 
Herman said this was possible, but needed to be assessed. 

Action: David raised concern relative to 3 . 3Vdc input if this is standard PCI card that 
could go in any slot. How to resolve? 

Action: Herman to determine feasibility of low profile heat sink and required flow rate. 
Next step: make mock ups of modules and chassis for evaluation this for Monday. 


Tom Eich 

MicroUnity Systems Engineering, Inc . 
255 Caspian Dr. Sunnyvale, CA 94 089 
(408)734-8100, (4 08)734-8136 fax 


tbe@microunity . com 


Exhibit C10 


Page 155 of 356 


From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Friday, January 13, 1995 12:55 AM 
Tom Eich' 

'boxers'; 'dbulfer'; 'pandora' 

Pandora meeting minutes/actions, 1/12 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Thu Jan 12): 

>6) Noel to investigate with tbr, dbulfer, and geert the implications of 
»unsynchronized or disorderly power-up of the various bricks in Pandora, and 
»specify p/s and system level requirements accordingly. 

Moot with single power supply. 

This should not be a problem even with multiple supplies. Euterpe 
comes up executing from boot rom and does not require other Hermes 
devices to start up. Other devices must be identified, and configured 
via Cerberus before being accessed via Hermes. If necessary a delay 
could be introduced to ensure auiliary supplies are available. 

>9) David is preparing a BOM for the clock card; for now he sez to assume a 
»single crystal oscillator with 6 ECL parts at 1 Watt each. 

The system clock has moved to the PCI/Hermes bridge module. 

I don't see how that's compatible with the need to have the clock 
source on the Calliope module when it is present. If we have a 
defined slot that that module would occupy, which we will have 
to fill with a herminator if the Calliope module is absent, then I 
still think putting the clock source there is easiest. Does someone 
see a problem with that?n 

What system temperature sensing/thermal management is planned relative to 
each airmover and heat source? Need to determine level of sensing 
appropriate to disparate modules and heat source. Discussed having system 
monitoring components on bridge module. 

Question: Does Mnemosthene have on chip temperature sensing as do Euterpe 
and Calliope? 

Yes, mnemosyne has the same temperature sensor. (We actually need it 
as part of the bias calibration system.) In addition to the sensor 
there is also the same overtemperature shutdown circuit. 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, January 13, 1995 12:55 AM 

Tom Eich' 

'boxers'; 'd buffer*; 'pandora' 

Pandora meeting minutes/actions, 1/12 


Tom Eich wrote (on Thu Jan 12) : 

>6) Noel to investigate with tbr, dbulfer, and geert the implications of 
>>unsynchronized or disorderly power -up of the various bricks in Pandora, and 
>>specify p/s and system level requirements accordingly. 

Moot with single power supply. 

This should not be a problem even with multiple supplies. Euterpe comes up executing from 
boot rom and does not require other Hermes devices to start up. Other devices must be 
identified, and configured via Cerberus before being accessed via Hermes. If necessary a 
delay could be introduced to ensure auiliary supplies are available. 

>9) David is preparing a BOM for the clock card; for now he sez to assume a 
>>single crystal oscillator with 6 ECL parts at 1 Watt each. 

The system clock has moved to the PCI/Hermes bridge module. 

I don't see how that's compatible with the need to have the clock source on the Calliope 
module when it is present. If we have a defined slot that that module would occupy, which 
we will have to fill with a herminator if the Calliope module is absent, then I still 
think putting the clock source there is easiest. Does someone see a problem with that?n 

What system temperature sensing/thermal management is planned relative to 
each airmover and heat source? Need to determine level of sensing 
appropriate to disparate modules and heat source. Discussed having system 
monitoring components on bridge module. 

Question; Does Mnemosthene have on chip temperature sensing as do Euterpe 
and Calliope? 

Yes, mnemosyne has the same temperature sensor, (We actually need it as part of the bias 
calibration system. ) In addition to the sensor there is also the same overtemperature 
shutdown circuit . 


Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday, January 13, 1995 8:31 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hb BOM 99.0 initiated by hopper completed @ Fri Jan 13 
06:26:21 PST 1995 with exit status 0.. chip 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Friday, January 13, 1995 12:17 PM 
'rnewton@ic.eecs. berkeley.ed u' 
(Fwd) Disk Arrays for Digital Video 


Forwarded mail from <gregg@hts . microunity . com> ("Gregg Kellogg") 


To: newton@eecs.berkeley.edu 


Richard, 


I thought you would find this interesting as I recall you describing your experiences 
trying to get your PowerMac to do video well. 


Date: Thu, 12 Jan 1995 15:48:19 -0500 
From: boykin@gte.com (Joseph Boykin) 
To : digvid- l@ucdavis . edu 

Subject: Experiences building a Disk Array for Digital Video 
Message-ID: <ab3b44d60c0210047f 97® [132 .197 .14 .175] > 

I have been asked by a number of people to summarize my experiences putting together a 
RAID subsystem for use with digital video. This is a report on those experiences. It is 
longer than expected, but I have tried to write down a lot of what I have uncovered over 
the past six months . It also tries to explain some of the matters that must be considered 
when putting such a system together. For example, *why* were the sustained data rates of 
3.5MB/s, 5.5MB/s and 6.5MB/s of interest to me? Read on and find out. 

First, let me give some background. I do not do digital video professionally, it is 
purely a hobby, but I'm what you would call a "serious hobbyist". I have been doing video 
for a number of years, with my primary material source being underwater video (I'm a PADI 
& SSI instructor and teach courses in U/W video if anyone is interested!) I did my 
editing on a SONY EVO-9700, but there aren't any whiz-bang features in that deck, e.g. no 
transitions, and I prefer playing with digital over analog technology anyway. 

My end-goal is full-frame, full-motion NTSC video on the order of 5-15 minutes. I'd love 
S-VHS/Hi8 quality, but I don't want anything less than VHS quality. Even if my final work 
will be output to VHS quality tape, I want to keep my edits in as high a quality as 
possible. In other words, I want to be able to hand a tape to someone and have them see 
it on a TV and not just produce little 160x12 0 clips for CD-ROMs. 

Being a "do it yourselfer" at heart, I put together a system with a Quadra 84 0AV, Radius 
VideoVision Studio, and a RAID array. This document talks about my experiences getting 
that RAID array going and the ancillary things that went along with it.. 

Looking at the prices for pre -configured arrays, I decided to put one together myself. 
After all, how hard could it be? To answer that question in advance: I started this in 
June and I finished in January. 

I started with two Micropolis 2236AVS (3GB each) . These drives had reasonable capacity, 
reasonable speed and boasted dealing with Thermal Recalibration (TCal) well. Other than 
the fact that these drives a) consume a lot of power and b) run pretty hot, they are 
probably excellent for many applications. However, I ran into a serious problem; they 
don't stripe well. I put the drives on the same SCSI chain and was surprised to find that 
I only achieved about a 5% performance increase when striped. 

About 25% is more typical for RAID level 0 . I eventually learned that these drives do not 
handle SCSI-2 disconnect /reconnect well (or maybe at all) . If the drives were on separate 
SCSI chains, this wouldn't be a problem. Given that they were on a single chain, the 
ability to do disconnect/reconnect is required, OK, back to the drawing board. 

While Micropolis makes a big deal of their AV drives, in reality, many new drives handle 


Gregg 
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TCal fairly well. The manufacturers know that the newest large capacity and fast drives 
are going to be used in digital video, so they are trying to ensure their drives work well 
for this demanding 

environment. They do TCal less often and postpone TCal if a read or 
write 

operation is pended. What that means is that a new non-AV drive may do just fine for you 
(especially if your disk housing has good cooling) . 

Drives from both Micropolis and Seagate are the top picks in this category. 
Fujitsu and Conner also have mechanisms . that work well, but you need to be sure about a 
♦particular* mechanism before you buy it. You can guarantee yourself that any old drives 
or new drives that aren't at the top of the curve will not handle TCal well. Based on 
that, I chose four Seagate Barracuda 4's as my disks. The drives are big (4GB each) and 
fast (7200 RPM, 8ms seek, 1MB cache) and yes, they do postpone TCal. More on the drives 
later . 

Next: the hunt for a SCSI accelerator. There are several out on the market, but based on 
other people's experience in terms of both performance and reliability I narrowed down my 
choice to the ATTO and FWB cards. ATTO has a Silicon Express II Fast SCSI-2 card and a 
Silicon Express IV Fast/Wide card. Street prices are $725 and $990 respectively. FWB has 
their SCSI JackHammer card which supports Fast/Wide transfers at a street price of about 
$700. Rumor had it that the ATTO card was a bit faster, so I chose the ATTO SE II (I had 
bought "narrow" drives) . My logic was 

simple: with a RAID array and an accelerator, I probably would have enough performance for 
what I want. You'll see shortly that I was wrong. 

The card arrived long before the disks, so I couldn't test things out immediately. By the 
time I did, the card was about 2 months old and turned out to be flaky (the system would 
hang when I tried to do any significant amount of I/O to drives attached to the card) . I 
contacted ProDirect, who I purchased the card from, and their Tech support folks told me 
they didn't even have a system they could test it out on and, since the card was two 
months old, they wouldn't swap it for a new one anyway. I turned to ATTO, who preferred 
that I deal with ProDirect, since that is who sold it to me, but after telling them what 
PD said, they relented. I sent them my card and was pretty quickly told that "It worked 
for them" and it was returned to me . I was pissed. I tried the card in three systems (2 
84 0s and an 

80 0) again, with the same results. I returned the card to ATTO who still couldn't find 

anything wrong with it, but agreed to swap it for a new one. 

The new card arrived and works well (at least, it didn't crash my system). 

At this point, I started running a bunch of performance tests. I have three formatting 
utilities: FWB HDT VI. 6, Transof t 1 s SCSI Director Pro V3.07, and CharisMac's Anubis 
utility V2.52s (I've recently upgraded this to version 2.53 with PowerControl (lets you 
control mode page settings) and RAID software, but I have not used those features yet. 
NOTE: I have been told that the CharisMac RAID software is *not* very good in its current 
release) . I reformatted one drive with each of these and ran FWB ' s BenchTest and ATTOs 
performance utilities to see what I got. A short version of my results: Partition size 
doesn't matter (except that the FWB benchmark test thinks smaller partitions are faster), 
under System 7.5 cache size doesn't matter, and the FWB driver did pretty poorly. 

Test configuration: Q840AV w/80MB memory; System 7.5. Partition size was 2GB. Using the 
internal SCSI Bus I achieved: 


Driver Sustained Read Sustained Write 

FWB 2.8MB/S 3.2MB/S 

CharisMac 3 . OMB/s 3 . 6MB/s 

Transof t 3 . OMB/s 3 . 6MB /s 


As you can see, if you are using the internal SCSI bus the CharisMac and Transof t drivers 
were about the same with the FWB driver falling significantly behind. I don't know why; 
perhaps it is the driver itself, perhaps it was some mode page (the disk drive's firmware 
parameters) settings that the formatter set. My belief is that it is a combination of the 
two as an e.g. Transof t driver on an FWB formatted drive is faster than an FWB formatted 
drive with the FWB driver . I never looked into it enough to narrow down the cause any 
further. (It takes a *LONG* time to run these tests and since I didn't have to know why 
one was faster than another, I just cared which was faster -- there's a point where this 
being a hobby is an advantage!) 
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While these are interesting numbers (and caused me to reformat and initialize all the 
other drives I had access to at home and at work with the Transof t driver ! ) , for eventual 
use on an accelerator card it didn't matter. When a drive attached to the ATTO card is 
mounted you use a driver that is in the ATTO firmware. The same is true for the FWB card 
and any of the current crop of SCSI accelerator cards. The performance data was obtained, 
and were of interest, because they provide a baseline of comparison. 

I moved the drives back to the ATTO card and went to install the RAID software. I have 
both the ATTO ExpressStripe software and Trillium Research's Remus Limited. I started 
with the ATTO software (version 2.00) but the system crashed as the INIT was being loaded. 
ATTO gave me a free upgrade to 2.01 (tech support created an account on their system and 
let me dial-in via ARA to download the file, very nice of them), but that didn't work 
either. ATTO then gave me a Beta copy of their 3.0 software and that did work (and is 
much nicer to use) . ATTO Tech support didn't know why 2 . OX didn't work, but at that 
point, I didn't really care. 

Reliability of the 3.00 software wasn't very good (what do you want from Beta software?!?) 
Occasionally, the drives would become inaccessible. 

While ATTO was figuring this out, I switched to the Remus software which has an even nicer 
interface . 

Using the Remus software, I tried various configurations. I tried: 
striping across two, three and four drives 

changing the allocation unit anywhere between 16K per drive to 64K 

varied the logical file system size between 256MB and 4GB 

varied the size of the system buffer cache. 

My peak performance was approximately 5.2MB/s sustained read and 4.5MB/s sustained write. 
This surprises me. I would have expected writes to be faster (you can do "blind writes" 
and return control to the application before the actual write completes) . The WS 
software that "find"s throughput reports about 2.8MB/s from within Premiere V4 . 0 using QT 
2.0. 

These results were achieved using a 64K chunk across either 3 or 4 drives (the numbers 
were close enough the difference doesn't matter), with a 1GB file system. I have heard 
that striping across three drives is faster than across four, but I didn't see that. 
Note: The FWB benchmark tests generally show smaller partitions as having better 
performance. The reason for this (I think) is that their random write tests have to move 
the disk heads less, thus reducing seek times. Sustained transfer rate, the number of 
interest in digital video capture, was the same regardless of partition size. I consider 
the effect of partition size to be an artifact of the benchmark and not a real factor in 
performance. 

I was disappointed with the results as my "dream" was to get about 6.5MB/s through to the 
application. To do full-frame (640x480) full-motion (60 

fields/sec) VHS quality video takes somewhere around 3MB/s if you have a reasonably clean 
signal. With a "great" signal, this could drop even further. Both my Sony EVO 9700 and 
camcorder have S-video in/out (S-video has the video signal split into two separate 
signals "luminance" and "chrominance", plus separate lines for audio), so the signal is 
pretty good. (RGBS (Separate Red/Blue/Green/Sync) signals would be cleaner, but no 
consumer, and few "pro-sumer" equipment has them. RF connections (all audio and video 
signals combined onto one cable- typical for consumer gear) would be the worst and hence 
require more bandwidth for the same level of quality. 

If I want S-VHS quality I'd need about 5 . 5MB/s . My goal of 6.5MB/s gives me a little 
extra so that if a random TCal hits, or the drive needs to retry an I/O, I should be able 
to survive it. I doubt if I will actually capture at 6.5--the difference between 5.5 and 
6.5 is generally not visible, even to an experienced eye. Of course, if I'm digitizing 
images with a lot of detail, and hence do not compress well, that extra throughput would 
come in handy. 

So, my 2.8MB/S was disappointing. I would have been satisfied if I had 3.5MB/s as then I 
could have done VHS+ quality and been happy enough, but with 2.5 that was not possible, 
and S-VHS quality was totally out of the question. 
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Now what? If you missed it, I chose the ATTO Silicon Express II card and Fast SCSI-2 
drives. That was the mistake. Thinking that those drives could do lOMB/s I figured that, 
when striped and with an accelerator card, I wouldn't have too much problem meeting my 
3.5MB/s minimums. I was wrong. 

I went back to the folks I bought the drives from, Direct Connections, and they agreed to 
take back the drives and sell me four Fast/Wide Barracuda 4's. They gave me a 100% credit 
on everything I bought! It wound up costing a "few bucks" to make the switch (wide drives 
are more expensive), but it wasn't that bad. I had to do a little arm twisting there, but 
DC was * superb* when it came to handling this problem. Without any question, I can 
endorse people buying from them. (Tell Dave I said Hi) . 

Now for the accelerator card. I needed to swap the SE II for an SE IV. I went back to 
ProDirect, told them my sob story, etc. and they basically hung up on me. Even though 
they sold me a flaky card, they couldn't/wouldn't even attempt to deal with the problem, 
and most importantly, ATTO was willing to do just about anything to convince them they 
should do this (e.g. provide new packaging, certify the card was OK, 

etc) they wanted to have nothing to do with me. From a pure business standpoint I can't 
really blame them. After all, the card was five months old at this point (even though I 
only had a working system for about two weeks), from a customer satisfaction stand point, 
and from the standpoint of having nothing to lose (ATTO was willing to stand behind the 
"used" 

card), and I was going to buy the more expensive SE-IV, they didn't even want to consider 
it. More than the fact that they wouldn't help, it was their attitude that was bad, and 
for that reason, I have no intentions of going back to ProDirect again. 

When Direct Connections shipped the four fast/wide Barracuda 4's, I also bought a Silicon 
Express IV card from them. That leaves me with a Silicon Express II to sell, so if anyone 
wants it, I currently have an SE-II that I'm looking to sell. A good card, just not what 
I needed . 


Anyway, I put the system together and began running some tests. 

Performance was *signif icantly* better (I should hope sol). Using Remus Limited RAID 
level 0 software and FWB BenchTest to measure performance, I achieve the following: 

Configuration Sustained Read (MB/s) Sustained Write (MB/s) 


Single drive: 5.4 9.3 

Two drives: 8.4 13.3 

Three drives: 8.9 13.3 

Four drives: 9.4 13.2 

FWB (2 drives): 8.2 9.2 


All tests were done on a Q840AV running System 7.5, numerous INITs (I fill the bottom of 
the screen on startup), and four fast/wide Barracuda 4s (ST15150W) . I chose to benchmarks 
with all INITs enabled as that would be my execution environment, rather than a minimal 
system (although I turn AppleTalk off, don't use a Screensaver, etc) . I prefer "real 
world" 

scenarios. However, I ran a subset of the benchmarks with most INITs disabled (I still 
needed QuickTime, WS, Remus and the like) and found that there was no significant 
difference in performance results (it was slightly faster without the INITs, but not by 
enough to mean anything). This surprised me, but I'm not complaining. I haven't tested 
the performance with and without INITs with the WS "find" command, but I would expect 
that there would be a slight hit. 

Except for the last test, all drives were connected to an ATTO SiliconExpress IV card with 
V9 PAL and Version 1.4 firmware. The partitions were all 2GB logical partition and were 
the first partition on the disk (additional partitions are generally slower) . The final 
number was using an FWB SCSI JackHammer card and FWBs RAID Toolkit software. 
Remus is supposed to work with the FWB card, but I could not get it to do so. As the FWB 
card was borrowed from a friend, I did not have the time to diagnose the problem. This 
test was done using two drives (the most the FWB software supports) . Note: One strange 
problem was found with the FWB 

card: when that card was installed, my system would not boot from my standard startup 
disk. Instead, it always went to a backup system folder I keep on a different drive. 
Once the system was up I could manually mount the other partition. Strange. 
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Why is read performance so much less than write? I believe the answer has to do with both 
the ATTO hardware and Remus software, although I haven't looked into it enough to find 
out. My guess is that, between the two, they are simply buffering write requests and 
immediately returning control to the application prior to the write taking place, never 
mind actually completing. The result Is high (and fairly constant) write throughput) . 

The configuration I am using has four 4GB partitions striped across four drives. Using 
four drives has several advantages and disadvantages. 

Additional drives help read performance. As each drive has a 1MB cache, if I only access 
one partition at a time, I effectively quadruple my on-board disk cache. How much that is 
also helping read performance I cannot estimate, but the end result is the same. In 
addition, the large per-drive cache also helps in dealing with TCal--the drive controller 
can buffer data while the mechanism is unavailable during TCal . The downside is that with 
more drives there is a higher probability of failure. In addition, if I lose one drive I 
lose 16GB of data. For many, that could be enough reason to stay away from this 
configuration! On the other hand, for myself, I am not concerned about the loss. First, 
as I've said before, this is a hobby; the world will not end for me if I get set back a 
little. Second, I have two 8mm Exabyte tape drives on my system and do automated nightly 
backups with Retrospect. Even with a catastrophic failure, I won't lose much. 
I'm 

a big believer in backups I 

The Radius VideoVision Studio "find" command reports about 5.8MB/s (5.9 without audio) 
through to Premiere. Slightly less than my optimal S.5, but more than the 5.5 I really 
needed for S-VHS quality. At this point, I'm happy and am capturing and editing full- 
motion, full-frame video and the fish are gorgeous! 

Effect of partition size: as in the past, I see a significant difference in FWB's overall 
index of performance based on partition size. The larger the partition, the worse the 
rated performance. Again, I consider this to be an artifact of the benchmark test, not a 
true measure. Regardless, for digital video my interest is in sustained transfer rate. 
Even if the performance is worse with larger partitions, my measurements show no 
difference in sustained transfer rate as a function of partition size. 

Effect of buffer cache: I am currently using System 7.5. Apple made some significant 
changes to their disk buffer cache algorithms in this release. 

Previously, a larger buffer cache would not help performance and, especially for digital 
video, could hurt performance. I ran the same tests using buffer cache sizes of 32KB, 
192KB, 1MB and 2MB and found no significant difference between them. 

I've seen 17MB/s in ads, why aren't these numbers even close?: 

Several RAID vendors advertise about 17MB/s in their ads. They do so by using *two* SCSI 
accelerator cards. For most systems, using two SCSI channels doesn't buy you much. I've 
traded benchmark numbers with several people using Seagate Barracuda drives on 8100/80 "s 
(which has two SCSI 

busses) and their performance is about the same as mine using a single bus. 
However, when using an 840AV (which has a very fast NuBus), dual SCSI channels can help-- 
in fact, if the numbers are accurate, it looks like it helps to the tune of about 3 0% (and 
about $1, 000 ! ) . 

That 1 s the good news . The bad news is that these are not real-world benchmark numbers . 
My bet is that the NuBus and CPU are saturated at that point and not much else is going to 
go on. Given that the goal of all that throughput is to capture and play back video, when 
another NuBus card like the WS is also sitting on the bus, your actual throughput may go 
*down* . 

This is because there is too much bus contention, and limited bus perormance. I recently 
had the opportunity to demonstrate this to an acquintance who had such a setup- -to say the 
least, he was surprised that his very expensive RAID array was hurting rather than helping 
him! He pulled the second NuBus card and we started capturing video with fewer dropped 
frames and more throughput. This may be counter- intuitive until you realize that you 
these cards are using "more than their fair share" of a very limited resource. Note that 
using multiple SCSI accelerators will work a lot better when we have faster busses (e.g. 
PCI) and faster CPUs. 


Acknowledgements and comments about vendors: 

ATTO: ATTO was pretty amazing. I think those guys are triple jointed because they bent 
over backwards for me in more ways than I could count . 
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They were there at every step of the way, doing everything possible to both make my system 
work and, more importantly, their attitude was right. When my SE-IV had some funny 
symptoms, they volunteered to have me just ship the entire system, on their nickel, to 
them and they would take a look at it from there. The comment from ATTO was "you've been 
at this too long with too many problems, let's fix it." These guys, and in particular, 
Mike Woltz in tech support, are champs. 

Radius: Mike Jennings of Radius's digital video team, and one of the people who has been 
pulling *his* hair out over at Radius to make disk arrays work well in the digital video 
world and I have had numerous email exchanges on this topic. While I may be the owner of 
a WS, his advice and comments on my efforts have gone well beyond what one would expect 
from an engineer at such a company. His comments on this document (he proofread several 
pre-releases) have also been invaluable. Indeed, the notes on throughput requirements for 
various video quality and signal conditions are mostly his. 

Direct Connections: As I said previously, these folks have been very cooperative and 
willing to help. I haven't received, and didn't ] the type of technical support I received 
from ATTO and Radius, but they have been great to work with. If you need peripherals, I 
heartily recommend them. 

ProDirect: A good place to avoid. I'm sure many will reply saying how they had great 
experiences with ProDirect- -that is always true, some people have good and some have bad 
experiences with vendors. My experiences were uniformly bad. When ATTO tried to help, 
they didn't return ATTOs phone calls. It seems to me this is a place to avoid. 

Final note: What is described in this document is based on my own experiences. While I 
have received help from many corners, I have not stated anything that I have not directy 
experimented with and discovered myself. The errors are therefore exclusively my own. As 
I have done this work on my own time, with my own (or borrowed) hardware and software, 
this document does not represent opinions of, and is not endorsed by, my employer. I do 
not guarantee that you will have the same, or even similar results. 

This has been an interesting exercise. I hope to expand upon it if and when additional 
hardware and software become available to me. If so, I will announce the results and, 
eventually, make this information available electronically. 


Joseph Boykin 

Principal Investigator 

Distributed Computing Systems 
GTE Laboratories, Inc. 

First Vice-President 

IEEE Computer Society 

Email : j . boykin@computer . org 


End of forwarded mail from <gregg@hts .microunity . com> ("Gregg 

Kellogg") 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: hopper (Mark Hofmann) 

Sent: Friday, January 1 3, 1 995 1 : 1 8 PM 

To: 'Bill ZuravlefF 

Cc: 'tbr (Tim B. Robinson)' 

Subject: Re: planet crashed 

Bill Zuravleff writes: 
hopper, 

Planet crashed on me while compiling euterpe pla's. 
I don't know if this is planet's fault or if I just 
wasn't sticking my tongue out correctly. Anyway, 
you said let you know. I'm going to try again. 

A log file is: 

/u/billz/euterpe/verilog/bsrc/dcacheeasy_V.simlog.planet.crashed 

Regards, 
billz 

Bill, 

I'd like to have a look but I'me having a little trouble. Where is 
the input file? Where is the core file? From where did you run make? 

-thanks, 
hopper 
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From: hopper (Mark Hofmann) 

Sent: Friday, January 13, 1995 1:20 PM 

To: 'Tim B. Robinson' 

Cc: 'woody (Jay Tomlinson)' 

Subject: Re: New version of Planet released 

Tim B. Robinson writes: 

Mark Hofinann wrote (on Fri Jan 13): 

When used with the new t2pla splitting capability (also just installed) 
large PL As can be broken down into smaller pieces, individually optimized 
by Espresso, and then re-combined for an substabtial gate savings. On 
a single example in Mnemo Alan saw ca. 35% reduction in atom count. 

That's great! Do we have any candidates in Euterpe? 

I believe Jay has a PLA that might be susceptible to this technique. 

-hopper 
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From: hopper (Mark Hofmann) 

Sent: Friday, January 13, 1995 1:46 PM 

To: 'billz (Bill Zuravleff)' 

Cc: 'tbr (Tim B. Robinson)'; 'torn (Thomas Laidig)' 
Subject: planet dump 


Hi Bill, 

Well I'm stumped on this one. The core file is indeed from Planet. However, 
I can run that checked-in version of that PLA just fine. 

Here's what gdb has to say: 

gdb-4. 1 1 planet.ex /n/ghidra//s2/euterpe/veriIog/bsrc/uu/core 

Core was generated by 'planet.ex'. 

Program terminated with signal 1 1, Segmentation fault. 

#0 0x265d8 in _bufsync () 

(gdb) where 

#0 0x26568 in _bufsync () 
#1 0xfl9a2008 in _end () 
#2 0x26b8c in free () 
#3 0x26034 in fclose 0 

#4 0x46f0 in main (argc=0, argv=0xefff5bb4) at planet.c:388 

(gdb) print vlogfl 

$1 = (struct _iobuf *) 0x42430 

(gdb) print *vlogfl 

$2 = {_cnt = 8192, 

_ptr = 0x5adl8 "vdSel_l_2, rsrvdSel_N_l_2;\nor2J UrsrvdSel_l_2 (inst_N[31], i 
nst_N[30], rsrvdSel_l_2, rsrvdSel_N_l_2);\n\n//\"OR\" plane from planet.. \n\no 
rff3_l UrsrvdSel_0 (phi_A, phi_B, rsrvdSelNOO, rsrvdSel_N_2_J,"..., 
_base = 0x5adl8 "vdSel_]_2, rsrvdSel_N 1 2;\nor2_l UrsrvdSel_l_2 (inst_N[31], 
inst_N[30], rsrvdSel_l_2, rsrvdSel_N_l_2);\n\n//\"OR\" plane from planet...\n\n 
orff3_l UrsrvdSel_0 (phi A, phi_B, rsrvdSel_N_0_0, rsrvdSel_NJ2_l,"..., 
_bufsiz = 8192, _flag = 10, _flle = 4 '\004'} 
(gdb) 

It looks like fclose is seg faulting. 

Bill- did you try this more than once? Is it repeatable for you? 

Tom- could the named stream have gone away due to a network funny and 
caused this error? Any ideas? 

-thanks, 
hopper 
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From: mws (Mark Semmelmeyer) 

Sent: Friday, January 13, 1995 3:25 PM 

To: 'hopper (Mark Hofmann)' 

Cc: 'tbr (Tim B. Robinson)'; 'woody (Jay Tomlinson)'; 'dickson (Richard Dickson)'; 'billz (Bill 

Zuravleff)'; 'lisar (Lisa Robinson)'; 'geert (Geert Rosseel)' 
Subject: planet core dumps on iofs 


I have had some trouble with the new planet. I found that it helps if everything is run 
through PLAT to get the number of #'s right as planet expects (the default rule does this, 
but I had some driver stuff in yy that needed custom treatment that wasn't using PLAT). I 
also had some trouble in GT with the gt spear ly thing but I think that was because I hit *C 
at a bad time? So watch out. 

But now it wants to rebuild iofs.v from iofs.Veqn and core dumps: 


/u/chip/tools/bin/planet . ex: opening Espresso- format input file " iof s . optesp ' 

/u/chip/tools/bin/planet .ex: creating Verilog output file "iofs.v' 

/u/chip/tools/bin/planet .ex: creating Pirn output file "iofs. pirn' 

/u/chip/tools/bin/planet .ex: parsing PLA file and building datastructures . . . 

/u/chip/tools/bin/planet .ex: ## Input phase is not specified, 

/u/chip/tools/bin/planet . ex : PLA has 31 inputs 14 outputs 34 pterms 

/u/chip/tools/bin/planet. ex: Phase 11111111111111 

/u/chip/tools/bin/planet . ex: Making netlist... 

/u/chip/tools/bin/planet .ex: Writing Verilog file "iofs.v'... 

/u/chip/tools/bin/planet . ex: Writing Pirn file "iofs. pirn' . . . 

/u/chip/tools/bin/planet . ex: 1 output OR rank required 

/u/chip/tools/bin/planet . ex: Maximum primary input fanout: 20 [rst] 

/u/chip/tools/bin/planet . ex : Maximum input plane fanin: 6 [pterm 1] 
/u/chip/tools/bin/planet . ex: This pterm drives a maximum output plane 
fanin of: 9 [out<l>] 

/u/chip/tools/bin/planet .ex: Maximum input plane fanout: 1 [pterm 1] 

/u/chip/tools/bin/planet . ex: Maximum output plane fanin: 9 [out<l>] # 
/u/chip/tools/bin/planet .ex Version 0.1.19 Fri Jan 13 17:00:07 PST 1995 # 
/u/chip/tools/bin/planet . ex -clock -diffin -diffout -flipflop -pimWidth 200 -verilog 


The .optesp file is: 


#/n/auspex/s24/mws/euterpe/tools/bin/plat Version 0.1.9 Tue Dec 13 17:02:20 PST 1994 ## 
/n/auspex/s24/mws/euterpe/tools/bin/espresso.mu -s -s -s iofs.esp ## UC Berkeley, Espresso 
Version #2.3, Release date 01/31/88 

##/* $Id: iofs.Veqn,v 3.1 1994/07/15 10:47:17 LT tbr Exp $ */ ## PLA is iofs.esp with 31 
inputs and 14 outputs ## ON-set cost is c=34{34) in=98 out=34 tot=132 ## OFF-set cost is 
c=37(37) in=98 out=38 tot=136 ## DC-set cost is c=0(0) in=0 out=0 tot=0 ## Input phase is 
not specified. 

## ESPRESSO Time was 0.08 sec, cost is c=34(o) in=98 out=34 tot=l32 
#.i 31 
#.0 14 

#.ilb rst pre [13] pre [12] pre [11] pre [10] pre [9] pre [8] pre [7] pre [6] pre [5] pre [4] pre [3] 
pre[2] pre[l] m[3] m[2] m[l] m [0] state [13] state [12] state [11] state [10] state [9] 
state [8] state [7] state [6] state [5] state [4] state [3] state [2] state [1] #.obout[13] 
out [12] out [11] out [10] out [9] out [8] out [7] out [6] out [5] out [4] out [3] out [2] out [1] 
frame #.p 34 

#0 0110 1 00000000000010 

#0 0111 1 00000000000010 

#0 1000 1 00000000000010 

#0 1001 1 00000000000010 

#0 1010 1 00000000000010 

#0 1011--1 00000000000010 

#0 1100-1 00000000000010 

#0 11011 00000000000010 

#11 10000000000000 

#1-1 01000000000000 
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#1- -1- - 00100000000000 

#1 1 00010000000000 

#1 1 00001000000000 

#1 1 00000100000000 

#1 1 00000010000000 

#1 1 00000001000000 

#1- 1 00000000100000 

#1 1- 00000000010000 

#! 1 00000000001000 

#1 1 00000000000100 

#0 1 00000001000000 

#0 1 00000000100000 

# 0 1-- 00000000010000 

#0 1- 00000000001000 

#0 1 00000000000100 

#1 1 00000000000010 

#0 1 10000000000000 

#0 1 01000000000000 

#0 1 00100000000000 

#0 1 00010000000000 

#0 1 00001000000000 

#0 1 00000100000000 

#0 1 00000010000000 

# 1 00000000000001 #.e 


.i 31 
.o 14 
.p 34 

.inputnames rst pre [13] pre [12] pre [11] pre [10] pre [9] pre [8] pre [7] pre [6] . inputnames 
pre [5] pre [4] pre [3] pre [2] pre [1] m[3] m[2] m[l] ra[0] state [13] .inputnames state [12] 
state [11] state [10] state [9] state [8] state [7] state [6] .inputnames state [5] state [4] 
state [3] state [2] state [1] .outputnames out [13] out [12] out [11] out [10] out [9] out [8] 
out [7] out [6] out [5] .outputnames out [4] out [3] out [2] out [1] frame #. phase 
11111111111111 


0 0110 1 00000000000010 

0 0111 1 00000000000010 

0 1000 1 00000000000010 

0 1001 1 00000000000010 

0 1010 1 00000000000010 

o 1011--1 00000000000010 

0 1100-1 00000000000010 

0 11011 00000000000010 

11 10000000000000 

1_! 01000000000000 

1- -1 00100000000000 

1 1 00010000000000 

1 1 00001000000000 

1 1 00000100000000 

! ! 00000010000000 

1 1 00000001000000 

1 1 00000000100000 

1 1 00000000010000 

! ! 00000000001000 

1 1 00000000000100 

0 1 00000001000000 

o --1 00000000100000 

0 1-- 00000000010000 

0 1- 00000000001000 

0 1 00000000000100 

1 1 00000000000010 

0 1 10000000000000 

0 1 01000000000000 

o 1 00100000000000 

o 1 00010000000000 

0 1 00001000000000 

0 1 00000100000000 

o 1 00000010000000 

1 00000000000001 . e 
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From: 


tbr 


To: 


Sent: 


Subject: 


Friday, January 13, 1995 4:00 PM 
'lisar' 

forwarded message from Don Rozenberg 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Return -Path: <rozen> 

Received: from rhodan.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA25555; Fri, 13 Jan 95 12:30:45 PST 
Received: from localhost by rhodan.microunity.com (8.6.4/muse-sw.3) 

id MAA08449; Fri, 13 Jan 1995 12:30:44 -0800 
Message-Id: < 199501 132030.MAA08449@rhodan.microunity.com> 
X-Mailer: ELM [version 2.3 PL1 1] 
From: rozen (Don Rozenberg) 
To: tbr (Tim Robinson) 

Cc: iimura (Wally Iimura), guarino (Loretta Guarino) 
Subject: Unix test follow up 
Date: Fri, 13 Jan 95 12:30:44 GMT 


Wally has gotten his test case of UNIX code to work on "terp 
- -c". This code utilizes kernel code to handle GTLB misses and 
Protection Exceptions. Those exceptions are thought to be the 
principal features exercised by the UNIX kernel but not the STB code. 
The estimated running time on the icos box is about 1.5 hrs. We could 
probably reduce that estimate by simplifying the initialization code 
(scaffolding) which is also taken from the UNIX kernel and which 
accounts for about two thirds of the time. In addition, the test 
generates a number (250) random tests and if desired that could also 
be condensed. 


Don Rozenberg 

MicroUnity Systems Engineering, Inc. 
255 Caspian Drive, Sunnyvale, CA 94089 
(408) 734-8100 FAX (408) 734-8136 
End of forwarded message 


Tim, 
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From: noel (Noel Verbiest) 

Sent: Friday, January 1 3, 1 995 6:56 PM 

To: 'pandora'; 'boxers' 

Cc: 'noel' 

Subject: Pandora Power Requirements 


Herewith a first tabulation of the power supply requirements for Pandora. 

Please note that these are educated estimations. The real values will depend on which ISA 
and PCI cards will be used, how Euterpe and Caliope will come in, etc.. 


VOLTAGE /CURRENT REQUIREMENTS : 


Function 

3 .3V 

5V 

- 5v 

12 v 


12v 

Fan 

Other 


Euterpe Brick 

2 8A 

0 

0 

0 


0 

? 

? 

Mnemo 1 

15. 5A 

0 

0 

0 

0 


7 

7 


Mnemo 2 

15 . 5A 

0 

0 

0 

0 


7 

7 


Mnemo 3 

15 .5A 

0 

0 

0 

0 


7 

? 


Mnemo 4 

15. 5A 

0 

0 

0 

0 


? 

? 


PCI/H Bridge 

10A 

3A 

0 

0 

.5A 

0 . 1A 

? 

? 

Caliope 1 

2 OA 

1A 

0.5A 

1A 

0 

.5A 

? 

48V/0 

2A 

Caliope 2 

2 OA 

1A 

0.5A 

1A 

0 

.5A 

7 

48V/0 

2A 

ISA 1 Multi 

10 

0 

5A 

0 -5A 

0 

. 5A 

0 .1A 

? 

? 

ISA 2 

0 

5A 

0 .5A 

0.5A 

0 

.1A 

p 

7 


ISA 3 

0 

5A 

0.5A 

0.5A 

0 

.1A 

? 

7 


PCI 1 SCSI 

0 

5A 

0 

0.5A 

0 

. 1A 

? 

? 


PCI 2 SVGA 

0 

5A 

0 

0.5A 

0 

.1A 

7 

? 


PCI 3 E-net 

0 

5A 

0 

0.5A 

0 

.1A 

7 

? 


PCI 4 Spare 

8A 

5A 

0 

0 .5A 

0 

. 1A 

? 

? 


Prot . /Sign. 

0 

0.5 

0.5 

0.1 

0 

.1 

7 

? 


TOTAL 

8 6A 

4 0.5 A 

3 .OA 

6.1A 

1 

. 9A 

? 

4 8V/0 

4A 


POWER REQUIREMENTS : 

Function 3.3V 5V -5V 12V -12V Fan Other H 
Total 

Euterpe Brick 92.4W 0 0 0 0 ? ? 

92 .4W 

Mnemo 1 51.2W0 0 0 0 ? ? 

51. 2W 

Mnemo 2 51.2W0 0 0 0 ? ? 

51. 2W 

Mnemo 3 51.2W0 0 0 0 ? ? 

51. 2W 

Mnemo 4 51.2W0 0 0 0 ? ? 

51. 2W 

PCI/H Bridge 3 3.3W 15W 0 6W 1.2W ? ? 

55. 5W 

Caliope 1 66.6W 5W 2 . 5W 12W 6W ? 10W 
102 . 1W 

Caliope 2 66.6W 5W 2 . 5W 12W 6W ? 10W 
102 . 1W 

ISA 1 Multi IO 0 25W 2 . 5W 6W 1 . 2W ? ? 

34. 7W 
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ISA 2 0 25W 

34 . 7W 

ISA 3 0 
34 . 7W 

PCI 1 SCSI 0 25W 
32 . 2W 

PCI 2 SVGA 0 25W 
32 . 2W 

PCI 3 E-net 0 25W 
32 . 2W 

PCI 4 Spare 26. 4W 25W 
58 . 6W 

Prot./Sign. 0 2 . 5W 

7 .4W 


V Total 490. 1W 202. 5W 15W 73.2W22.8W? 10W 

823 . 6W 


If the Power Supply + Cooling is 72.5% efficient, then the Power drawn 
from a 

12 0 V AC outlet amounts to : 113 6 Watts. 

Adding a decent quality 21" monitor to the same outlet will require 
another 

200 Watts from that outlet. 

Which brings the system total to 1336 Watts. 

A typical outlet allows for 120 V x 12 A = 1440 Watts. 

The question marks in the "fan" column are there because it is not yet 
known with 

certainty whether we will have distributed cooling for each brick 
(requiring a 

dedicated "fan power buss") or centralized cooling (or a combination of 
both) . 

Herman is sweating the cooling this very moment. 

The "Other" column refers to the distribution of unusual power (e.g.: 48 
Volt DC 

for special VCO's) or "raw DC" (used to make "super clean" secondary 
voltages 

for audio or RF functions) . 

The "Prot./Sign." row refers to Protection and Signaling circuitry. It is 
the 

intend to measure temperature and other vital information at critical 
points in 

the box and display/ shut it down if need be. 

Comments and feedback invited. I'll be the keeper of the spreadsheets. 
Noel x787 


2.5W 6W 1.2W ? ? 
25W 2.5W 6W 1.2W ? 


6W 
6W 
6W 
6W 


1.2W 
1.2W 
1.2W 
1.2W 


2 . 5W 1 . 2W 1 . 2W 
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From: dbulfer (David Bulfer) 

Sent: Friday, January 13, 1995 8:04 PM 

To: 'Noel Verbiest' 

Cc: 'pandora'; 'boxers'; 'noel (Noel Verbiest)' 

Subject: Re: Pandora Power Requirements 


This is a little overstated. The PCI slots have an maximum of 25W, not the combined total 
of all supply currents. That is only useful in sizing the power supply. 

More realistic would be: 

POWER REQUIREMENTS : 

Euterpe Brick 92 W 

Mnerao 1 51 W 

Mnemo 2 51 W 

Mnerao 3 51 W 

Mnemo 4 51 W 

PCI/H Bridge 55 W 

Caliope 1 102 W 
Caliope 2 102 W 

ISA 1 Multi 10 25 W (Typical of 10W) 

ISA 2 25 W (Typical of 10W) 

ISA 3 25 W (Typical of 10W) 

PCI 1 SCSI 25 W (Typical of 10W) 

PCI 2 SVGA 25 W (Typical of 10W) 

PCI 3 E-net 25 W (Typical of 10W) 

PCI 4 Spare 2 5 W (Typical of 10W) 

Prot./Sign. 7 W 

737 W 

Add: 

* 1.2GB SCSI Disk 
.75A @ 5V 
,6A @ 12V 


11 W 

* 20" Color Monitor @ 33 0W 
For a total of 1078 W 

How much is available: 

* In a standard office environment, UL permits 80% of the circuit 

maximum 15A @ 11 0V => 12A 

* Assume you have a low AC line of 100 VAC (I suspect we spec 100 

12 0 VAC) . 

* Assume 99% Power Factor Correction 

* Assume that the power supply is 75% efficient. 

You have 891 W of available power (12 A * 100V * 99% * 75%) . 

===> This means we are short 187 W! 

David 
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From: Tom Eich [tbe@MicroUnity.com] 

Sent: Friday, January 13, 1995 8:12 PM 

To: 'David Bulfer' 

Cc: 'noel@WlicroUnity.com'; 'pandora@WlicroUnity.com' 

Subject: Re: Pandora Power Requirements 


>This is a little overstated. The PCI slots have an maximum of 2 5W, not 
>the combined total of all supply currents. That is only useful in 
>sizing the power supply. 
> 

>More realistic would be: 


> POWER REQUIREMENTS : 


>Euterpe Brick 

92 

W 




>Mnemo 1 

51 

w 




>Mnemo 2 

51 

w 




>Mnemo 3 

51 

w 




>Mnemo 4 

51 

w 




>PCI/H Bridge 

55 

w 




>Caliope 1 

102 

w 




>Caliope 2 

102 

w 




> 

>ISA 1 Multi 10 

25 

w 

(Typical 

of 

10W) 

>ISA 2 

25 

w 

(Typical 

of 

10W) 

>ISA 3 

25 

w 

(Typical 

of 

10W) 

> 

>PCI 1 SCSI 

25 

w 

(Typical 

of 

10W) 

>PCI 2 SVGA 

25 

w 

(Typical 

of 

10W) 

>PCI 3 E-net 

25 

w 

(Typical 

of 

10W) 

>PCI 4 Spare 

25 

w 

(Typical 

of 

10W) 

> 

>Prot . /Sign. 

7 

w 




> 
> 

737 

w 





Don't forget fans: 1 for Euterpe, say 2 for the four Mnemos, 1 for the PCI area all at 
12V® . 8A steady state for a total of 3 8.4 W load. 

>Add: 
> 

> * 1.2GB SCSI Disk 

> .75A @ 5V 

> .6A @ 12V 

> 

> 11 W 
> 

> * 2 0" Color Monitor @ 33 0W 
> 

>For a total of 1078 w 
> 

>How much is available: 
> 

> * In a standard office environment, UL permits 80% of the circuit 

> maximum 15A @ 11 OV => 12A 

> * Assume you have a low AC line of 100 VAC (I suspect we spec 100 - 

> 12 0 VAC) . 

> * Assume 99% Power Factor Correction 

> * Assume that the power supply is 75% efficient. 
> 

>You have 891 W of available power (12 A * 100V * 99% * 75%) . 
> 

>===> This means we are short 187 Wl <==- 
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> 

>David 
> 


Even more if the fans are included; btw, 
module load? 

Regards, 

-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


what comprises the 102 W number for Calliope 


tbe@microunity . com 
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From: dbulfer (David Bulfer) 

Sent: Friday, January 1 3 T 1 995 8: 1 6 PM 

To: 'David Bulfer' 

Cc: 'noel@MicroUnity.com'; 'pandora'; 'boxers'; 'noel (Noel Verbiest)' 

Subject: Re: Pandora Power Requirements <=== Correction 


Sorry, I double counted the monitor power supply efficiency. 


This is a little overstated. The PCI slots have an maximum of 25W, not the combined total 
of all supply currents. That is only useful in sizing the power supply. 

More realistic would be: 

POWER REQUIREMENTS : 

Euterpe Brick 92 W 

Mnemo l 51 W 

Mnemo 2 51 W 

Mnemo 3 51 W 

Mnemo 4 51 W 

PCI/H Bridge 55 W 

Caliope 1 102 W 
Caliope 2 102 w 

ISA 1 Multi 10 25 W (Typical of 10W) 

ISA 2 25 W (Typical of 10W) 

ISA 3 25 W (Typical of 10W) 

PCI 1 SCSI 25 W (Typical of 10W) 

PCI 2 SVGA 25 W (Typical of 10W) 

PCI 3 E-net 25 W (Typical of 10W) 

PCI 4 Spare 25 W (Typical of low) 

Prot./Sign. 7 W 

737 W 

Add: 

* 1.2GB SCSI Disk 
.75A @ 5V 
,6A @ 12V 


11 W 

********* Corrected calculations below ********** 
Total DC power - 748 W 

* Assume 99% Power Factor Correction 

* Assume that the power supply is 75% efficient. 

DC Power Supply Power is 74 8 W / (99% * 75%) = 1007 W 
Now add: 

* 20" Color Monitor @ 3 3 0W (my xterm's monitor spec) 
For a Total AC power of 13 3 7 W. 

How much is available: 
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* In a standard office environment, UL permits 80% of the circuit 

maximum 15A @ 11 ov => 12A 

* Assume you have a low AC line of 100 VAC (I suspect we spec 100 - 

120 VAC) . 

* Therefore the available power is 1200 W 
===> This means we are short 13 7 W <=== 


David 


> 


> 


> 


o 


David Bulfer (_) / (_) 


email : dBulf er@MicroUnity . Cora 


SnailMail: MicroUnity Systems 


Phone : 
FAX: 


408-734-8590 x282 
408-734-8136 


Engineering, Inc . 
255 Caspian Drive 


Sunnyvale CA 94089-1015 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Friday, January 13, 1995 8:48 PM 
"hopper (Mark Hofmann)' 
'hardheads'; 'karzes' 
New version of Planet released 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Fri Jan 13): 

This version supports the new "-merge outFile" option. You can now invoke 
Planet like so: 

planet [other options] -merge merged plal .esp pla2,esp pla3.esp ... 

Planet will read the separate .esp files and combine them into a single 
PLA which can then be written out as a monolithic .v file (called "merged.v" 
in this example). Note that signals in the module name will begin with 
those given in plal followed by pla2, etc. 

When used with the new t2p!a splitting capability (also just installed) 
large PLAs can be broken down into smaller pieces, individually optimized 
by Espresso, and then re-combined for an substabtial gate savings. On 
a single example in Mnemo Alan saw ca. 35% reduction in atom count. 

That's great! Do we have any candidates in Euterpe? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig) 

Friday, January 13, 1995 9:27 PM 

'hardheads' 

'torn (Thomas Laidig)' 

atlas and cronus areas created 


I've created the toplevel directories for two new chip design areas: 
atlas 

This is the cmos equivalent of proteus, so named because it 
will support the world (well, the world of cmos, anyway -- hey, 
names with any mnemonic significance are getting scarce). I've 
installed a bare bones version of ged, which undoubtedly needs 
improvement, but should be enough to let people start drawing 
schematics. 

cronus 

This is the cmos version of euterpe, named because we really 
have to get this done on time. Only the top-level directory 
exists as of now. 


En j oy . 


ooooO Ooooo 


( _) L > 

\ ( tau ) / 
(_) (_) 
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From: tbr 

Sent: Saturday, January 14, 1995 4:24 PM 

To: 'Lisa Robinson' 

Subject: regression/ 1887: c_euterpe_wrap BOM: 201 .0 regression run - 714195.12167 

Follow Up Flag: Follow up 
Flag Status: Red 

Lisa Robinson wrote (on Sat Jan 14): 

>Number: 1887 
>Category: regression 

>Synopsis: ceuterpewrap BOM: 201.0 regression run - ./14195. 12167 
Please take me off the list !!! 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Monday, January 16, 1995 4:30 AM 

Tim B. Robinson' 

'age (Alan Corry)'; 'lisar (Lisa Robinson)'; 'billz (Bill Zuravleff)'; 'dickson (Richard Dickson)'; 
'geert (Geert Rosseel)'; 'mws (Mark Semmelmeyer)'; 'woody (Jay Tomlinson)' 
Re: Coprolite polishing 


Tim B. Robinson writes: 

I think we ought to think seriously about freezing the version we are 
using on euterpe . Even in the absense of new problems like the 
unexpected instance name changes, we are losing a lot of time with 
constantly having to regenerate things. 

The latest code will definitely improve some of the PLAs Alan has been looking at for 
Mnemo. So far we don't have an example of a similar improvement with Euterpe. So perhaps 
we freeze the Euterpe version to what we are currently running. 


-hopper 
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From: paulp (Paul Poenisch) 

Sent: Monday, January 16, 1995 10:52 AM 

To: Tom Laidig' 

Cc: 'hardheads' 

Subject: Re: atlas and cronus areas created 


> I've created the toplevel directories for two new chip design areas: 
> 

> atlas 

> cronus 
> 

> Enjoy. 


> ooooO Ooooo 

> (_><_> 

> \( tau )/ 

> (_) (_) 
> 

I agree with solo, this is going to get confusing if different chips, projects and 
machines are sharing the same name. I would recommend the name tisiphone, which has 
phonetic similarities to both terpsichore and euterpe and may have mythological 
significants on several levels. 

Paul. 
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From: 
Sent: 
To: 
Cc: 


Subject: 


tbr (Tim B. Robinson) 

Monday, January 16, 1995 12:28 PM 

'hopper (Mark Hofmann)' 

'age (Alan Corry)'; 'lisar"; 'billz (Bill Zuravleff)'; 'dickson (Richard Dickson)'; 'geert (Geert 
Rosseel)'; 'mws (Mark Semmelmeyer)'; 'woody (Jay Tomlinson)' 
Coprolite polishing 


Mark Hofmann wrote (on Sun Jan 15) : 


Hi, 


I've got yet another version of Planet to release. This version should 
"only" affect merged PLAs (the new planet option) . I noticed when 
multiple PLAs are given to Planet it is possible that they share minterms . 
If so, these can be merged. (Normally the input to Planet comes only from 
a single Espresso run and Espresso quashes redundant minterms) . 

So... Should I do a release? 

I'll wait for resposnes. 

I think we ought to think seriously about freezing the version we are using on euterpe. 
Even in the absense of new problems like the unexpected instance name changes, we are 
losing a lot of time with constantly having to regenerate things. 
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From: lisar (Lisa Robinson) 

Sent: Monday, January 16, 1995 1:15 PM 

To: 'craig'; 'lisar' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Mon Jan 16 11:14:30 PST 1995 

Copy number: 284 

Copy registered to: Jim LaBarre 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore .macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore . ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: wampler (Kurt Wampler) 

Sent: Monday, January 16, 1995 2:07 PM 

To: 'geeif; 'vo' 

Subject: Wire lengths for 99.2% route 


Hi, 

The wire lengths for the 9 9.2% route (not including Cerberus) can be found 
in: 

/ n / r hodan / s 2 / wampl e r / eurou t e / geer t _eu terpe-iter.cap 
- Kurt 
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Subject: 


From: 


Sent: 
To: 

Cc: 


dbulfer (David Bulfer) 

Monday, January 16, 1995 4:05 PM 

'David Bulfer' 

'tbr@MicroUnity.com'; 'mnemo' 
Re: Mnemo generated PCI interrupts 


TBR wrote on (Mon Jan 16) : 

Can we model this on the existing event register, where, by choice of 
address we have the option to do reagular writes, or bit set and bit 
clear operations where the data value is the mask for the bits to be 
set cleared? 

The mechanism described in Terpsichore should be augmented for this purpose. The 
interrupt status has 2 customers with different requirements. The PCI bus interrupt is 
the logical OR of all the enable status bits. 

Pandora needs : 

- a non-blocking read to get status and 

- a non-blocking write to clear it . 

Hestia needs: 

- a non-blocking write to set status, 

- a read that blocks until the status register is zero, and 

- a write that blocks until the bitwise-AND of the write data and 
status register is zero. 

The last two block on the opposite condition of the event register, that is, the zero 
rather than non-zero condition. It is this way that Hestia knows when the interrupt has 
been serviced. 


David 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday, January 16, 1995 5:06 PM 

'craig' 

'David Bulfer'; 'mnemo' 

Re: Mnemo generated PCI interrupts 


Craig, can you comment on this please? 
David Bulfer wrote (on Mon Jan 16) : 


TBR wrote on (Mon Jan 16) : 

Can we model this on the existing event register, where, by choice of 
address we have the option to do reagular writes, or bit set and bit 
clear operations where the data value is the mask for the bits to be 
set cleared? 

The mechanism described in Terpsichore should be augmented for this 
purpose- The interrupt status has 2 customers with different 
requirements. The PCI bus interrupt is the logical OR of all the 
enable status bits. 

Pandora needs : 

- a non-blocking read to get status and 

- a non-blocking write to clear it . 

Hestia needs: 

- a non-blocking write to set status, 

- a read that blocks until the status register is zero, and 

- a write that blocks until the bitwise -AND of the write data and 
status register is zero. 

The last two block on the opposite condition of the event register, 
that is, the zero rather than non-zero condition. It is this way that 
Hestia knows when the interrupt has been serviced. 


David 
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From: 
Sent: 
To: 

Subject: 


mws (Mark Semmelmeyer) 
Monday, January 16, 1995 7:26 PM 
'euterpe' 

EUTERPE WORKING: SMux64 not to be supported 


We have a bug in the current implementation that SMux64 behaves the same as SMAS64; i.e. 
SMux64 writes a destination register when it is not supposed to. Currently there are many 
other bug, squeezing, timing, placement, and routing fixes of definitively higher 
priority. Also the software people tell me that SMux64 is the much less useful variation 
of the two, because usually one wants the old load data when using a semaphore operation. 
Since the user can always restore SMAS64 ' s data register to get the same effect as SMux64, 
SMux seems only an infrequently usable minor performance enhancement. 

Thus I think we should begin expecting SMux64 to become a reserved instruction. Let's 
assume this becomes official Friday at noon. 
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From: 
Sent: 
To: 

Subject: 


mws (Mark Semmelmeyer) 
Monday, January 16, 1995 7:26 PM 
'euterpe' 

EUTERPE WORKING: SMux64 not to be supported 


We have a bug in the current implementation that SMux64 behaves the same as SMAS64; i.e. 
SMux64 writes a destination register when it is not supposed to. Currently there are many- 
other bug, squeezing / timing, placement, and routing fixes of definitively higher 
priority. Also the software people tell me that SMux64 is the much less useful variation 
of the two, because usually one wants the old load data when using a semaphore operation. 
Since the user can always restore SMAS64 • s data register to get the same effect as SMux64, 
SMux seems only an infrequently usable minor performance enhancement. 

Thus I think we should begin expecting SMux64 to become a reserved instruction. Let's 
assume this becomes official Friday at noon. 

Date: Mon, 16 Jan 1995 18:36:43 -0800 
From: craig (Craig Hansen) 
To: euterpe, mws 

Subject: Re: EUTERPE WORKING: SMux64 not to be supported 

smux is also useful for writing a subset of the bits of an octlet, as may occur in 
modifying a bit field in a structure. smux also permits (but obviously does not require) 
a much faster implementation, as it doesn't modify reg state and can therefore be 
performed with timing of stores; i.e. it can be buff erred. 

It seems foolish to me to nuke the instruction just to avoid fixing a bug. 


Craig 
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From: 
Sent: 
To: 

Subject: 


craig 

Monday, January 16, 1995 7:37 PM 
'euterpe mws' 

Re: EUTERPE WORKING: SMux64 not to be supported 


smux is also useful for writing a subset of the bits of an octlet, as may occur in 
modifying a bit field in a structure. smux also permits (but obviously does not require) 
a much faster implementation, as it doesn't modify reg state and can therefore be 
performed with timing of stores; i.e. it can be buff erred. 

It seems foolish to me to nuke the instruction just to avoid fixing a bug. 


Craig 
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From: 
Sent: 
To: 

Subject: 


craig (Craig Hansen) 

Monday, January 16, 1995 8:37 PM 

'euterpe'; 'mws' 

Re: EUTERPE WORKING: SMux64 not to be supported 


smux is also useful for writing a subset of the bits of an octlet, as may occur in 
modifying a bit field in a structure. smux also permits (but obviously does not require) 
a much faster implementation, as it doesn't modify reg state and can therefore be 
performed with timing of stores; i.e. it can be buff erred. 

It seems foolish to me to nuke the instruction just to avoid fixing a bug. 


Craig 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, January 17, 1995 12:20 AM 

To: 'Geert Rosseel' 

Subject: Re: Top-level Euterpe 


Geert Rosseel writes: 

I build euterpe BOM 2 02. 

-> I moved It between at and nd . . not pretty but it fits . . 

-> I moved the blocks in the datapath around as Rich wanted to 
solve the wiring congestion 

mst - xlu - mc - es - gf - rg - cr 

I mirrored the datapath section of es and gf , but I did not mirror 
the control 

Kurt : Can you route this one and see if it gets better ? 

It's in the usual place : 
/n/ghidra/ s3 /geert / euterpe/verilog/bsrc/gards 

Hi Geert, 

Okay, great. So everything in BOM 202.0 places now? (is BOM 202 the most recent BOM?) 
-mark 
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From: wa m pier (Kurt Wampler) 

Sent: Tuesday, January 1 7, 1 995 1 1 : 1 6 AM 

To: 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'tbr'; 'woody' 

Subject: Re: Top-level Euterpe 


Geert writes: 


> I built euterpe BOM 202. 

> -> I moved It between at and nd . . not pretty but it fits . . 

> -> I moved the blocks in the datapath around as Rich wanted to 

> solve the wiring congestion 

> mat - xlu - mc - es - gf - rg - cr 

> I mirrored the datapath section of es and gf , but I did not 
mirror 

> the control 

> Kurt : Can you route this one and see if it gets better ? 

> It 1 s in the usual place : 

> /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards 

I've picked up the GARDS source files and will run some routing iterations. 
- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Tuesday, January 17, 1995 3:10 PM 

'geert (Geert Rosseel)' 

'billz'; 'brianP; 'dickson'; 'hopper'; 'mws'; 'tbf 

Euterpe timing errors 


Geert Rosseel wrote (on Tue Jan 17) : 


Hi, 


Here are the timing violations of the latest top-level run. 
This is the one that has It between at & nb, and the 
re -arranged datapath. 

More detailed info is in : 

/n/ ghidra/s3 /geert/euterpe/verilog/bsrc/gards/geert_euterpe- top . stat 

(look for HARD ERROR) 


The errors are in 4 areas : 

--> in uu : we know about that 

--> uu to rest of world 

XLU to rg now that we moved rg : I believe that 
with care in placement and routing, we can 
deal with these 

--> errors in and out rib {to/from dr, hcl, uu, cc, ..) 


Jay is working on errors in uu, and Rich and I are looking at 

the xlu/rg path. Can anyone please look at the "nb errors" or the "uu 

to rest of world errors" ? 


The uu- >at paths are known problems. I will address this as part of the in uu problems. 
Once I get the 1 in uu 1 problems under control I plan on to a real placement to make an 
attempt at solving some of the uu- >rest_of_world . 


Jay 
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From: 
Sent: 
To: 

Subject: 


craig 

Tuesday, January 17, 1995 4:38 PM 
'dbulfer mnemo pandora' 

Re: What does PCI reset mean to Mnemo/Hermes/Hestia l/F 


What's going to generate this reset, and what state is lost? 

Signalling an error packet causes a Euterpe machine check, which may make bring-up 
sequencing more complicated. 

Hestia should be asserting Cerberus reset (grounding SD) until the system is ready to come 
out of reset. 


Craig 
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Subject: 


Sent: 

To: 

Cc: 


From: 


dbutfer (David Butfer) 

Tuesday, January 17, 1995 5:55 PM 

'Craig Hansen' 

'mnemo'; 'pandora' 

Re: What does PCI reset mean to Mnemo/Hermes/Hestia l/F 


> 


> What's going to generate this reset, and what state is lost? 

> Signalling an error packet causes a Euterpe machine check, which may 

> make bring-up sequencing more complicated. 

> 

> Hestia should be asserting Cerberus reset {grounding SD) until the 

> system is ready to come out of reset. 


In the event the interface card is plugged into a PC, it would be some combination of the 
CPU and mother board. 

The other possibility is a Hestia plugged into a Pandora. I would assume that someone 
would be driving the Cerberus to reset Euterpe &. the Mnemo on the PCI bridge. But what 
about the Mnemo that is plugged into the PCI as a Hestia l/F? If Euterpe gets a machine 
check, I assume that we would like to reset the PCI bus. What does that mean to Hestia? 

As far as what data is lost, at the very minimum, the PCI configuration of all devices is 
reset. I suspect that you'd have to reset all state machines that may be in some phase of 
PCI I/O. That would likely trash anything that Hestia might be doing. 


> Craig 


> 


David 
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Subject: 


Sent: 

To: 

Cc: 


From: 


rich (Rich McCauley) 

Tuesday, January 17, 1995 6:16 PM 

'graham' 

'pandora'; 'tbr"; 'rich' 
CMOS clocks 


As of the moment , 1 1 ve no plans for designing any PLLs for the CMOS version of euterpe . 
Both PLLs on the mobimos version are there solely for the convenience of being able to 
change the operating frequencies of the sofa clock and Hermes channel through software and 
independently from one another. 

Thus, there is no need to change oscillator modules on the board to adjust the system 
operating frequencies. For the CMOS euterpe I would contend that it doesn't make sense to 
spend the design effort to implement PLLs at this time. The required clocks can be 
generated outside the chip either through an external PLL or simply with a clock module. 
I believe this is the right way to go, but I think we need to air this issue and agree on 
a course of action. 

If my suggestion is adopted, board space will need to be allocated. 
Comments? 


rich 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, January 17, 1995 7:29 PM 

'dbulfer (David Bulfer)' 

Craig Hansen; 'mnemo'; 'pandora' 

Re: What does PCI reset mean to Mnemo/Hermes/Hestia l/F 


David Bulfer wrote (on Tue Jan 17) : 


> What's going to generate this reset, and what state is lost? 

> Signalling an error packet causes a Euterpe machine check, which 

> may make bring-up sequencing more complicated. 
> 

> Hestia should be asserting Cerberus reset (grounding SD) until 

> the system is ready to come out of reset . 


In the event the interface card is plugged into a PC, it would be some 
combination of the CPU and mother board. 

The other possibility is a Hestia plugged into a Pandora. I would 
assume that someone would be driving the Cerberus to reset Euterpe & 
the Mnemo on the PCI bridge. But what about the Mnemo that is plugged 
into the PCI as a Hestia I/F? If Euterpe gets a machine check, I 
assume that we would like to reset the PCI bus. What does that mean to 
Hestia? 

As far as what data is lost, at the very minimum, the PCI 
configuration of all devices is reset. I suspect that you'd have to 
reset all state machines that may be in some phase of PCI I/O. That 
would likely trash anything that Hestia might be doing. 

This raises anothoer issue. We have been assuming that we can use the same Cerberus for 
both Pandora and Hestia, using the multi-master capability. Either side then can 
explicitly reset chips on the other side by writing the appropriate reset bit in octlet 6 
in the target device. However, we will not be able to use the blanket reset by holding SD 
down without resetting both systems . Do we have any concern that Hestia may get 
sufficiently hosed that this is the only way (short of cycling the power) to reset it? 
This should not be the case in the absense of hardware bugs because the Cerberus slave 
operation should not be dependent on software activity. However, if we felt it was a 
requirement, then some sort of isolation would be needed. 


> 


> Craig 


> 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, January 17, 1995 9:38 PM 

'rich (Rich McCauley)' 

'graham'; 'pandora'; 'rich' 

CMOS clocks 


Rich McCauley wrote (on Tue Jan 17) : 

As of the moment, I've no plans for designing any PLLs for the CMOS version 
of euterpe. Both PLLs on the mobimos version are there solely for the 
convenience of being able to change the operating frequencies of the sofa 
clock and Hermes channel through software and independently from one another. 
Thus, there is no need to change oscillator modules on the board to adjust 
the system operating frequencies. For the CMOS euterpe I would contend that 
it doesn't make sense to spend the design effort to implement PLLs at this 
time. The required clocks can be generated outside the chip either through an 
external PLL or simply with a clock module. I believe this is the right way 
to go, but I think we need to air this issue and agree on a course of action. 
If my suggestion is adopted, board space will need to be allocated. 
Comments? 

I think I agree with this approach. To the extent that the operating 

frequency will be a lot lower than the ECL version we are unlikely to want to operate the 
Hermes channels more slowly than the CPU, so extra flexibility there is pointless. So 
long as we would be able to arrange the external clock source to be slaved off a reference 
which could be the reference output from Calliope we would be able to interwork OK. 


Tim 
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Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Wednesday, January 18, 1995 12:21 AM 

'Richard Dickson' 


Subject: 


'geert (Geert Rosseel)' 
Re: rich_euterpegards 


Richard Dickson writes: 
geert or mark, 
i 'm stuck . . . 

i was running rich_euterpegards and it failing and i dont see it ?? 
see gards.log in my euterpe/verilog/bsrc dir 

i was trying ctioi cp cj and iq in my place and route 
attempt fist time, i just added cp. it worked with ctioi cj and iq. 


Sorry for the late reply, In the make. log the last lines read: 
/n/rama/s5/dickson/euterpe/tools/bin/pim2pif : Processing the 
gards/rich_euterpe- 
iter .pirn file . . . 

/n/rama/s5/dickson/euterpe/tools/bin/pim2pif : In pirn section 2 couldn't find .mo 
reObstructions . . /ctioi/ctioi-base . obs Exiting... 


gards/rich_euterpe- iter . pirn 

there is the line 

.moreObstructions . . /ct ioi/ctioi-base . obs 

But Pim2pif can't find the file /ctioi/ctioi-base . obs to open for reading, so it Exits. 
Probably this file is not under CVS control and somebody forgot to check it in. You might 
be able to do a CVS update on the ctioi directory, of just copy it from /u/chip/ . . . to 
your local area. 


Hi Rich, 


In 


- hopper 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 1:37 AM 

'bobm* 

'euterpe' 

Euterpe Octlet 31 


We need to clarify the documentation for Euterpe Cerberus octlet 31 please. 

1. Bits 47:43 There is no doubling of this value. 

The actual clock frequency on the Hermes channel is this number times the reference 
frequency. 

2. Bits 39:35 Clarify the doubling. For a PLLO divide ratio value of <n> the sofa clock 
frequency will be 2<n> times the reference. 

(This is largely historical and comes from the fact that we used to use a clock which was 
active on both edges, but was then changed to be active only on a single edge at double 
the frequency.) 

3. Note needed. If one PLL is bypassed, so must the other be. 
Operation is undefined if one PLL is bypassed and the other is not. 

4. Note needed. When the PLLs are bypassed, the only legal values for the divide ratio 
fields are 5 for PLL1 divide ratio and 10 for PLLO divide ratio. In this case the Sofa 
clock frequency will be equal to the supplied reference frequency and the Hermes frequency 
will be half that. (This restriction is not strictly necessary, but it's harder to 
explain whats really going on. The true restriction is that PLL1 divide ratio must be <= 
5 and PLLO divide ratio must be >= 6. However, whatever values are chosen subject to this 
restriction, the actual clock frequencies used will be the same.) 

5. The asterisks for bits 47:43, 42, and 41 should be removed. 


Tim 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Wednesday, January 18, 1995 2:10 AM 
'geert'; 'hopper' 
rich_euterpegards 


geert or mark, 

i 'm stuck . . . 

i was running rich_euterpegards and it failing and i dont see it ??? 
see gards.log in my euterpe/verilog/bsrc dir 

i was trying ctioi cp cj and iq in my place and route attempt fist time, i just 
added cp. it worked with ctioi cj and iq. 


dickson 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Wednesday, January 18, 1995 10:55 AM 

Vo' 

'geerf 

killed pgroute 


After reporting its inability to route PHI_A2P over to the XCDECSW cell in Cerberus, my 
PGROUTE didn't seem to get any further. I let it run all night, and when I came in this 
morning, it hadn't gotten any further, and hadn't touched the dff since yesterday at 
11:40AM. So I killed it. Hopefully moving the XCDECSW cell will cure the problem, but it 
would be good to do this soon and confirm that we can indeed get a good PGROUTE of 
euterpe . 


- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


billz {Bill Zuravleff) 

Wednesday, January 18, 1995 11:50 AM 
'wampler (Kurt Wampler)' 
'geert (Geert Rosseel)' 
gplace read only? 


Kurt, 


I was using gplace to examine components and nets of global timing violations in the 
snapshot area - /n/ghidra/s3 /geert/euterpe/verilog/bsrc/gards . 

I use the following command to invoke gplace - invoke gplace geert_euterpe-iter -inbat 0 & 

and exit with "exit nosave" menu option. I was just nervous that this procedure wrote any 
files whatsoever. I assume if I clobbered some crucial design file, I'd hear about it. 
Is there a way to invoke gplace, read only, or should I not worry about this? 


Thanks, 
billz 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Wednesday, January 18, 1995 11:58 AM 

'billz' 

•geert' 

Re: gplace read only? 


Bill Z. writes: 


> I was using gplace to examine components and nets of global timing 

violations in the snapshot area - 

>/n/ghidra/s3/geert/euterpe/verilog/bsrc/gards . 

>I use the following command to invoke gplace - invoke gplace 

>geert_euterpe-iter -inbat 0 & 

> 

>and exit with "exit nosave" menu option. I was just nervous that this 
>procedure wrote any files whatsoever. I assume if I clobbered some 
>crucial design file, I'd hear about it. 

>ls there a way to invoke gplace, read only, or should I not worry about 
>this? 


As far as I know, there's no way to invoke gplace in "readonly mode". 


you did was "safe" in that the exit -nosave -nopof option will not write 
anything in the dff. If you used just exit-nosave, then it rewrites the 
pof {placement output file) upon exit, but still doesn't update the dff. 
GPLACE always writes an output listing file (defaults to gplace. lis, but 
may be renamed), and typically updates the " .vrf " file and a file called 
" invoke . com" . 

When I want to view someone else's design in with gplace or redit, I use 
the following procedure: 

mkdir scratch 
cd scratch 
In -s 

/n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards/geert_euterpe- iter .dff . 
cp /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards/geert_euterpe-iter . vrf 

In -s /u/chip/technology/mobimos/gards/*234 . 

(edit the vrf and change the "colorin" parameters for gplace & redit to 
point to these links: gplace . mobi2 34 & redit . mobi234 respectively), 
then invoke gplace or redit 

Since you're in the same group as geert, and since his dff files seem to 
be group -writ able, there is no OS protection against accidentally trashing 
his files, so... be careful. :-) 


What 


Kurt 
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From: graham (Graham Y. Mostyn) 

Sent: Wednesday, January 18, 1995 1:04 PM 

To: 'rich'; W 

Cc: 'pandora' 

Subject: Re: CMOS clocks 


I also agree with this approach. I would point out, however, that Tim's suggestion about 
use of Calliope as a reference clock source is undesirable, since digital -only Pandora 
systems may not require Calliope to provide I/O. 

Separate clock arrangements would then have to be made for the CMOS Euterpe . 
Graham . 

> From tbr Tue Jan 17 19:37:40 1995 

> Date: Tue, 17 Jan 1995 19:37:34 -0800 

> From: tbr (Tim B. Robinson) 

> To: rich (Rich McCauley) 

> Cc: graham, pandora, rich 

> Subject: CMOS clocks 

> Content -Length: 1342 


> Rich McCauley wrote (on Tue Jan 17) : 

> 

> As of the moment, I've no plans for designing any PLLs for the 

> CMOS 
version 

> of euterpe. Both PLLs on the mobimos version are there solely for 
the 

> convenience of being able to change the operating frequencies of 

> the 
sofa 

> clock and Hermes channel through software and independently from 

> one 
another . 

> Thus, there is no need to change oscillator modules on the board to 
adjust 

> the system operating frequencies. For the CMOS euterpe I would 
contend that 

> it doesn't make sense to spend the design effort to implement PLLs 

> at 
this 

> time. The required clocks can be generated outside the chip either 
through an 

> external PLL or simply with a clock module. I believe this is the 
right way 

=> to go, but I think we need to air this issue and agree on a course 

> of 
action. 

> If my suggestion is adopted, board space will need to be allocated. 
Comments? 

> 

> I think I agree with this approach. To the extent that the operating 
> 

> frequency will be a lot lower than the ECL version we are unlikely to 

> want to operate the Hermes channels more slowly than the CPU, so extra 

> flexibility there is pointless. So long as we would be able to 

> arrange the external clock source to be slaved off a reference which 

> could be the reference output from Calliope we would be able to 

> interwork OK. 
> 

> Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


stick (Bruce Bateman) 

Wednesday, January 18, 1995 1:10 PM 

'michael' 

'euterpe' 

Re: Huns models 


Chris Michael previously said: 


People, 

I've updated the Huns MOS models to align with the information provided in their design 
rules. The devices described in the design rules bear absolutely no resemblance to our 
previously modeled devices (time to re- simulate everything) . 

The mobi-like format for NMOS and PMOS devices can be found in the following library: 
.lib 1 /u/chip/technology/huns/hspice/models . lib ' huns_60 

Right now, the library contains only the models for nominal NMOS and PMOS transistors. 
These models are still Level 3; therefore, they'll still have kinks and poor length and 
narrow width scaling. 

Things these models should reflect fairly accurately: 

- basic device I-V parameters (Idsat, Vt) 

- device capacitances (Cgate, C j , Cgd/Cgs) 

Things these models will probably have problems with: 

- Current scaling with gate length (or narrow widths) 

- Output conductance 

- Transition from linear to saturation 

- Basic I-V accuracy (it fits to Idsat and Vt - but otherwise??) 

- Temperature dependence (not much information in the design rules) 


I guess that I'm a little confused here. Are these "new" models that have been fit to the 
CMOS14 data that the huns gave us last week? 

Or are you saying that they are just a tweek of the old huns BiCMOS models that were 
already on the system? If this is the case, are you saying that their old models bare 
some resemblance to their current CMOS 14 transistors? 


Chris 


BB 
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Subject: 


Sent: 

To: 

Cc: 


From: 


michael (Chris Michael) 

Wednesday, January 18, 1995 1:29 PM 

'Bruce Bateman' 

'euterpe' 

Re: Huns models 


Bruce Bateman wrote : 
> 

> I guess that I'm a little confused here. Are these "new" models that 

> have been fit to the CMOS 14 data that the huns gave us last week? 

The models I released yesterday are just crude fits to the data the huns provided in their 
design rules. 

> Or are you saying that they are just a tweek of the old huns BiCMOS 

> models that were already on the system? 

I did start with their old models - but I had to change over half of the parameters (Vt, 
DL, DW, tox, Cgs, Cgd, C j , Rs, Rd ...) to arrive at a model which approximates their new 
CM0S14 process. Luckily, this is rather simple to do with Level 3 models (well, it's much 
easier than BSIM2) . 

> If this is the 

> case, are you saying that their old models bare some resemblance to 

> their current CMOS14 transistors? 

The only resemblance is that the minimum drawn L is still 0 . 6um and they're still MOS 
devices. I'd say that everything else has changed. 

Eventually, the Huns will provide us with full-blown BSIM2 models. 


Chris 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, January 18, 1995 1:53 PM 
'guarino'; 'sandeep'; 'gmo'; 'jeffm'; 'wayne' 
'hestia' 

Software Bringup Meeting Minutes - January 18, 1995 


Software Bringup Meeting 


January 18, 1995 


Next Meeting: 


January 25 at 10:00 am. 


Attendees: jeffm, guarino, wayne, gmo, sandepp, doi 


New Action Items 


Item: Rerun dcacheharder and icacheharder tests and get cycle count 
results . 
Who : doi 

Status: [01/11] New. 

The dcacheharder and icache harders tests should run now. 


Review of Action Items 


Item: More investigation on CBI and workstation interface issues. 
Who: guarino, wayne 

Status: In limbo for a day or so. . . . 

There needs to be some decisions made as to whether or not 
this work is going to occur. 


Item: Implement parallel port device driver for Linux on PC. 
Who: jerry, doi 

Status: [12/14] In progress. 


Item: Define and implement a snapshot environment for the HW and SW 

simulators . 
Who: jeffm, gmo, guarino 
Status: [11/30] In progress 

Jeff showed us first cut at his high-level thoughts. The team 
will review and supplement the proposal. 


Item: Continue trying to find either source code for parallel drivers 

or descriptions of hardware so we can write out own. 
Who: gmo sgi machines 
Who: doi sun machines 
Status: [11/23] Progress continues. 

Called Aurora (company suggested by Avcom) and have pestered them 
daily trying to get anwers . 


Exhibit CIO 


Page 209 of 356 


Item: Build scripting/UI capabilities above gdb for regression tests, 
who : doi 

Status: on hold until the the boot, gdb boot stub, and virtual devices 

are complete. 


Item: Create performance test plan 
Who : j e f f m , guar ino 

Status: [11/30] No progress this week as focus was on functionality. 

We continue to run tests to help us compare terp vrs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware . 


Item: Simulator needs to understand "reset 1 
Who : gmo 

Status: [11/30] In progress. Target finish of 1/2 0. 


Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who: sandeep/gmo 

Status: In progress. Target finish of [1/10] 1/20. 

Booting the microkernel should be finished by 1/2 0. 

The ability to boot arbitrary code supplied by gdb is expected 

by 1/17. 

Completed Items 


Item: Run dcacheharder test and get cycle count results. 
Who: doi 

Status: [01/11] Done. 

The test was unable to run with the current BOM. 

Item: Add Unix-like tests to software acceptance tests. 
Who: iimura 

Status: [11/30] Done. 


Test Status 


Jeff talked about test and debug status. 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Wednesday, January 18, 1995 2:10 PM 
'lisa' 

execute Joop hit a notdecoded instruction 


I ran ~gregg/stb/apps/tv/tv. reg (which uses "tv" and "../.. /ukernel/ukernel" 

binaries) . This simulator ran for a simulated 56 ms and resulted in the following output: 

0.676932 ms(ao=0):NO SIGNAL: wait for message 
0.923956 ms (ao=0) : ACQUIRE PAT: wait for PAT 
0.979863 ms (ao=0) : ACQUIRE PAT: new PMT PID 2 
1.024206 ms{ao=0) : ACQUIRE PMT: wait for video PID 
1.063743 ms (ao=0) : ACQUIRE PMT: new video PID 16 
1.110039 ms{ao=0) : INIT VIDEO: decode video 

56.099159 ms (ao=0) : INIT VIDEO: Initialize DLWS execute_loop hit a notdecoded instruction 

If you copy tv, kernel, and tv.reg anyplace else and run tv.reg it should give you the 
same results. 

I have the same thing running with the stb-stable/bin/terp and it's run for over 13 0 ms . 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: 
Sent: 
To: 

Subject: 


jeffm (Jeff Marr) 

Wednesday, January 18, 1995 5:11 PM 
'euterpe'; 'hestia' 

Simulation State Snapshots - heterogeneous environments 


There are several reasons to want to be able to transfer high-level machine state between 
different environments. The transfer that would be desirous NOW is from terp (the 
instruction level simulator) to HW simulation {verilog, zycad, and ikos) environments. 

We will be running the Euterpe Ukernel Tests and the Unix Kernel in HW simulation. Running 
the Unix Kernel, even on the IKOS box, as a monolithic hunk of SW would take about 3 days. 
Also, the Ukernel Tests all go though essentially identical initialization sequences that 
don't need to be repeated all the time. It is desirous to run the SW to certain points on 
terp, and transfer the "state" to the HW simulation environments. 

Obviously, entire state information cannot be transfered, but it is possible to transfer 
an "architectural" snapshot of of the state. Below, I describe what I think is required to 
do this. 


In zycad and verilog simulation environments we can {if not now, soon) preload the 
following HW structures: 

dram, rom, cerb registers, tag, buffer, gtlb, register file. 

Gtlb and register files are not loadable on the IKOS, however. 

If we assume that IKOS is our primary target, it means that the following are not 
pre loadable : 

calliope interface state {event daemon armed/disarmed) 

5 X pc and priv (gmo - could always limit to high priv.) 

event mode {gmo - could always limit to event mode.) 

system registers (timer , timer match, event regiser, event mask, 

etc.) 

event daemons/ calliope state 
gtlb, ltlb 
register files 

Euterpe SW running on terp would need to save the state of the registers and structures 
mentioned above into a preloadable place (dram or dbuf fer) , or terp itself would need to 
save them directly. If terp does it, the saved data will need to be put into the dram or 
dbuf fer preload files . Gmo feels that that the mkimg tool can do that, and also has 
expressed his preference that terp dump out state in elf format. On the HW simulator 
side, Euterpe SW would need to grab the values from their saved places and "unsnap" the 
state . 

The sequence would be: 

Snap: (on terp) 

(Squirrel ===== put in dram or dbuf fer) . 
Squirrel away the state of cerb registers 6, 7, 10. (more?) 
Squirrel away the pc and priv + state of event mode (how know?) . 


Snapshot 


Definition- 
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Squirrel away the state of the event mask, the ltlb. 

Squirrel away the Calliope interface state (daemon armed, disarmed) . 
Keep pointers to same . 

Dump dram, tag, buffer, gtlb, register file (elf format) . 

Proccess dump information: (shell) 

Blow up dump into preload files (dram, dbuffer, tag, etc.) . 
(mkimg) 


Unsnap: (on hw simulator) 

Load dram, tag, buffer, gtlb, register file. 
Reload squirreled away info, 
branch to squirreled away pc's. 

Notes : 

No changes required to HW simulator environments. 
Does not account for Calliope state. 

There is another snapshot that is not addressed here - from 
a bringup box back to a simulation environment. Many of the 
same principles apply. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 7:16 PM 

'graham (Graham Y. Mostyn)' 

'pandora'; 'rich' 

Re: CMOS clocks 


Graham Y. Mostyn wrote (on Wed Jan 18) : 

I also agree with this approach. I would point out, however, that Tim's 
suggestion about use of Calliope as a reference clock source is undesirable, 
since digital -only Pandora systems may not require Calliope to provide I/O. 
Separate clock arrangements would then have to be made for the CMOS 
Euterpe . 

We are making provision for a separate 54MHz reference when there is no Calliope. Hoever, 
if there is a Calliope, it's essential we can run everything from a single reference or 
the Hermes channels will not function. Assumeing we still want the cleanest possible 
clock to Calliope, we must then be able to generate the CMOS euterpe clock from the 54MHz 
Calliope output. 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 7:23 PM 

•foe' 

'pandora' 

Euterpe module form factor 


We need to be sure that we will be able to fit the CMOS Euterpe module into the Pandora 
backplane. The form factor I have seen for the module based on the ECL Euterpe version 
looks tight. Although we do not yet know what the packaging for the CMOS version will be, 
we do know the die will be much bigger, so it would be wise to be conservative in allowing 
spare board area. It's possible we may not be supporting the SDRAM interface on the CMOS 
version, which would give us some free board space in the long dimension, but we should 
not count on that. The narrow dimension could be a problem. 

We may need to accommodate additional components on the CMOS version (eg a separate PLL or 
clock buffer devices) . 

What is the advantage in making this board narrower than the Mnemosyne module? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 7:42 PM 

'craig' 

'euterpe'; "dickson" 
Cerberus octlet 6 


We may have something wrong in Cerberus octlet 6. Bits 62 and 63 are the logic clear and 
circuit reset respectively. These bits have a default value of 1 right now, and retain 
that value after reset completes. (It's the bits in octlet 7 that actually show when the 
reset is active or completed.) So, if you do a read modify write to set some other field 
you have to explicitly mask off these bits or you get a reset when you store the value 
back. It is the act of writing to octlet 6 with one of these bots set that actually 
triggers the reset, not the static level of the bit. So would it make more sense if these 
bits always returned 0 on a read? 


Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 7:54 PM 

'hopper (Mark Hofmann)' 

'hardheads' 

New verison of Planet released 


Mark Hofmann wrote (on Wed Jan 18) : 


I have released a new version of Planet which warns of unused inputs and 
exits with a fatal error if undriven outputs are detected. A case of 
undriven (but subsequently used) outputs was found in the CC section of Euterpe. 
This error would presumably have been caught by simulation. Planet now 
provides an early warning. 

It should also have been caught by csyn, but the only floating inputs fred refers to in 
the last report wer tau inputs which I doubt should have been driven from a PLA. Fred, 
can you check on this please. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Eich [tbe@MicroUnity.com] 
Wednesday, January 18, 1995 8:38 PM 
Tim B. Robinson' 
'pandora@MicroUnity.com' 
Re: Euterpe module form factor 


>We need to be sure that we will be able to fit the CMOS Euterpe module 
>into the Pandora backplane. The form factor I have seen for the module 
>based on the ECL Euterpe version looks tight . Although we do not yet 
>know what the packaging for the CMOS version will be, we do know the 
>die will be much bigger, so it would be wise to be conservative in 
>allowing spare board area. It's possible we may not be supporting the 
> SDRAM interface on the CMOS version, which would give us some free 
>board space in the long dimension, but we should not count on that. 
>The narrow dimension could be a problem. 
> 

>We may need to accommodate additional components on the CMOS version 
> (eg a separate P1»L or clock buffer devices). 

> 

>What is the advantage in making this board narrower than the Mnemosyne 
>module? 


No advantage any longer; at one time, there might have been one in terms of packaging 
efficiency at the box level, but with Calliope modules looking like mnemo modules, there 
is none now. I'll update the layout accordingly and re-distribute it. 


> 


>Tim 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
{408)734-8100, {4 08)734-8136 fax 


tbe@microunity . com 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, January 18, 1995 8:43 PM 

'jeffm (Jeff Marr)' 

'euterpe'; 'hestia' 

Simulation State Snapshots - heterogeneous environments 


Jeff Marr wrote (on Wed Jan 18) : 

There are several reasons to want to be able to transfer high-level machine 
state between different environments. The transfer that would be desirous 
NOW is from terp (the instruction level simulator) to HW simulation 
(verilog, zycad, and ikos) environments. 

We will be running the Euterpe Ukernel Tests and the Unix Kernel in 
HW simulation. Running the Unix Kernel, even on the IKOS box, as a 
monolithic hunk of SW would take about 3 days. Also, the 
Ukernel Tests all go though essentially identical initialization 
sequences that don't need to be repeated all the time. It is desirous to 
run the SW to certain points on terp, and transfer the "state" to the HW 
simulation environments. 

I would like a better understanding of what the real need is here. We have the ability to 
checkpoint the hardware simulator, which gives us the basic ability to save the state 
after a fixed initialization sequence and pick up from there. When we are trying to run 
the unix kernel, are we saying that we never want to try the early stages on the hardware 
or that for some reason we would not do that till we knew the later stages would work? If 
we do want (eventually) to be able to get from startup to prompt, and if we are willing to 
debug things from the front forward as we go, then we can use the same checkpointing. 

However, if as a result of this exercise we are unlucky enough to still be finding a 
sigificant number of bugs (in the hardware, as opposed to the simulation scaffolding or 
the software we are trying to run) , then one might consider there is something to be saved 
by being able to start a hardware simulation from an advanced point after compiling in a 
hardware change. But, I would say this overlooks the basic fact that at that late stage 
in the game we should not be willing to ship the chip after making any change without 
rerunning a full regression test. More likely, we will be doing a detailed analysis of 
the problem and deciding if there is an acceptable software workaround which allows us to 
proceed without changing the hardware (ie until the second rev) . Given this, the ability 
to avoid re-running initialization code, which presumably represents a relatively critical 
piece of code that we must have confidence will run, seems moot to me. If we do not 
change the hardware, we could restart from a hardware checkpoint. If we do, we should 
rerun from the start. 

Obviously, entire state information cannot be transfered, but it is possible 
to transfer an "architectural" snapshot of of the state. Below, I describe 
what I think is required to do this. 

This could be critical. We are well aware that the really subtle bugs are the ones that 
only show up for particular conjunctions of events between the cylinders, or between the 
main pipe and the memory system, and where apparantly identical code works just fine in 
very slightly modified timing circumstances. So, if the goal is to try to ensure we do 
not have any killer problems lurking in there from the kernel's point of view, we have to 
be willing at some point to run for real with no cheating. From a hardware perspective, 
the programmer visible state of the machine is but a tiny fraction of the true state of 
the hardware . 

So, some questions: 

Are we sure that the cumulative amount of time saved by having this capability will offset 
the time we will spend getting the full path working? We need all hands on debugging the 
chip right now, not the scaffolding. 

Can we reduce this to a bootstrap loader which relies on nothing more than the ROM and 
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DRAM state to restart? These are the only things in the real systemm that we guarantee 
across a reset, so a solution that directly saves and restores the on chip memory images 
creates some exposure. While we have been using the ability to preload these arrays 
extensively in the early phases of verification and debug we cannot allow ourselves to do 
that at the end. The only acceptable final verification must run from the unmodified 
netlist with everything operating as it will for real. 

Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, January 18, 1995 9:34 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/gt BOM 68.0 initiated by brianl completed @ Wed Jan 18 
19:29:31 PST 1995 with exit status 0.. chip 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Thursday, January 19, 1995 4:36 AM 

'Geert Rosseel' 

Re: Freezing design rules 


Geert Rosseel writes: 
Hi Paul, 

We are getting close to finishing Euterpe and we need to finalize 
the design rules. We want to do that by tomorrow Jan. 20. 

We will assume that the current DRC flow is the final one. If there 
are any additions that you want to make, can you do that before the 
weekend ? We are currently editing the layout of Euterpe to make 
it pass the current DRC flow. 


Thanks for sending this mail, Geert. 

I reminded Paul yesterday about the freeze, but he had some loose ends still to clear up. 


Thank 1 s 
Geert 


-mark 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, January 19, 1995 6:03 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 78.0 initiated by woody completed @ Thu Jan 19 
04:00:55 PST 1995 with exit status 0.. chip 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Thursday, January 19, 1995 9:17 AM 

'geert'; 'torn'; Vo' 

'hopper'; 'tor' 

PGROUTE endless loop 


Looks like the current placement of euterpe (even with Tom Vo's adjustments to the XCDECSW 
cells in Cerberus) is putting PGROUTE into an endless loop. 

I'm going to try resurrecting an earlier version of PGROUTE that had specific patches to 
deal with a TAR we submitted on a similar problem about a year ago and see if it works any 
better. The current PGROUTE has been running for 17 hours, and hasn't updated the .dff 
since 3:55PM yesterday. 

I was afraid this might fall through a crack; Patrick Fitzgibbon, the programmer who did 
the PGROUTE fixes for us last winter/ spring confirmed for me back in September that his 
final fixes hadn't made it in to the 
7. 115 

release, and then he left the company. I will call SVR to find out whether his fixes made 
it into the upcoming 7.117 release. If they disavow all knowledge, I may need to provide 
them with a current test case. We never officially accepted closure on our TAR#1573 when 
this problem originally manifested itself. The patches that Patrick did were sufficient 
to let us PGROUTE Calliope, though. 


- Kurt 
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From: dbulfer (David Bulfer) 

Sent: Thursday, January 19, 1995 9:27 AM 

To: Tom EiclY 

Cc: 'tbr (Tim B. Robinson)'; 'pandora' 

Subject: Re: Euterpe module form factor 


> >We need to be sure that we will be able to fit the CMOS Euterpe 

> >module into the Pandora backplane . The form factor I have seen for 

> >the module based on the ECL Euterpe version looks tight. Although we 

> >do not yet know what the packaging for the CMOS version will be, we 

> >do know the die will be much bigger, so it would be wise to be 

> >conservative in allowing spare board area. It's possible we may not 

> >be supporting the SDRAM interface on the CMOS version, which would 

> >give us some free board space in the long dimension, but we should 

> >not count on that. The narrow dimension could be a problem. 

> > 

> >We may need to accommodate additional components on the CMOS version 

> > (eg a separate PLL or clock buffer devices) . 

> > 

> >What is the advantage in making this board narrower than the 

> >Mnemosyne module? 

> > 

> >Tim 
> 

> No advantage any longer; at 

> terms 
of 

> packaging efficiency at the 

> looking like mnemo modules, 
accordingly 

> and re-distribute it. 
> 

> -Tom 

> 

I'm not sure how Euterpe size is affected by Calliope, but ... 

Mnemo has considerablaly more board size that Euterpe. Calliope wants to be Mnemo sized 
or more (13 0x17 0) . Current models of Euterpe have a much smaller board size (90x13 5) . 
Wouldn't it make the mechanicals easier if all bricks had the same X and Y dimensions and 
varied in width only, preferably in quanta of one Mnemo unit (1 mu) ? 

David 


one time, there might have been one in 

box level, but with Calliope modules 
there is none now. I'll update the layout 


David Bulfer (_) / (_) 


email: dBulf erOMicroUnity . Com SnailMail: MicroUnity Systems 

Engineering, Inc . 

Phone: 408-734-8590 x282 255 Caspian Drive 

FAX: 408-734-8136 Sunnyvale CA 94089-1015 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Guillermo A. Loyola [gmo@MicroUnjty.comJ 

Thursday, January 19, 1995 10:52 AM 

'euterpe@gaea' 


tbr@gaea.microunity.com (Tim B. Robinson) writes: 
> 

> We may have something wrong in Cerberus octlet 6 . Bits 62 and 63 are 
■> the logic clear and circuit reset respectively. These bits have a 

> default value of 1 right now, and retain that value after reset 

> completes. (It's the bits in octlet 7 that actually show when the 

> reset is active or completed.) 

So the documentation should be changed. Currently both the TSA and the EMA manuals say 
that software is supposed to read octlet 6 to determine the cause of a reset. 

> So, if you do a read modify write to 

> set some other field you have to explicitly mask off these bits or 

> you get a reset when you store the value back. 

Under the current description, osftware should set them to zero after it has read them. 

> It is the act of 

> writing to octlet 6 with one of these bots set that actually triggers 

> the reset, not the static level of the bit. So would it make more 

> sense if these bits always returned 0 on a read? 

Yes, it seems better to me to make them return always zero. 


Gmo. 


Exhibit CIO 


Page 226 of 356 


From: Geert Rosseel [geert@rhea] 

Sent: Thursday, January 1 9, 1 995 1 1 :22 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert : 
Thu Jan 19 09:19:09 PST 1995 

/N/auspex/root/s41/euterpe-snapshot/euterpe/verilog/bsrc chip_euterpe crashed, geert 
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From: craig 

Sent: Thursday, January 1 9, 1 995 1 1 :27 AM 

To: 'for' 

Cc: 'dickson euterpe' 

Subject: Re: Cerberus octlet 6 


On Mnemosyne, and I assume Calliope as well, the part was to stay in reset or clear until 
the corresponding bit was explicitly cleared (set to zero) . Clearly, Euterpe must 
automatically come out of reset and clear, and in such a case, the Cerberus bits should be 
cleared by the end of the operation. 

Craig 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hchu (Herman Chu) 

Thursday, January 19, 1995 1 1:34 AM 

'tbe' 

'pandora' 

Euterpe module form factor 


Please bear in mind that the cooling scheme for the CMOS version might be completely- 
different from our Eu, since the power of the CMOS is estimated at 150 watts. The volume 
needed for cooling might be significantly larger than the CMOS version. I am still 
waiting on inputs from Tim and Geert on the junction temperature that they would like to 
see us achieve, in order to size a cooling system that will meet that target junction 
temperature. 


Begin Included Message 

>From tbr Wed Jan 18 17:22:47 1995 

Date: Wed, 18 Jan 1995 17:22:36 -0800 

From: tbr (Tim B. Robinson) 

To: tbe 

cc: pandora 

Subject: Euterpe module form factor 
Content -Length: 798 


We need to be sure that we will be able to fit the CMOS Euterpe module into the Pandora 
backplane . The form factor I have seen for the module based on the ECL Euterpe version 
looks tight. Although we do not yet know what the packaging for the CMOS version will be, 
we do know the die will be much bigger, so it would be wise to be conservative in allowing 
spare board area. It's possible we may not be supporting the SDRAM interface on the CMOS 
version, which would give us some free board space in the long dimension, but we should 
not count on that. The narrow dimension could be a problem. 

We may need to accommodate additional components on the CMOS version (eg a separate PLL or 
clock buffer devices) . 

What is the advantage in making this board narrower than the Mnemosyne module? 


Tim 


End included Message 
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From: geert (Geert Rosseel) 

Sent: Thursday, January 19, 1995 1 1:42 AM 

To: 'hchu'; 'tbe' 

Cc: 'pandora' 

Subject: Re: Euterpe module form factor 


Our current power estimate for Cronus ( = CMOS Euterpe) is closer to 100 W. We've changed 
to a 3.3 V process from a 5V process. 

We will do our design so that it works for a junction temperature of 
127 degrees. 

Geert 
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From: craig (Craig Hansen) 

Sent: Thursday, January 19, 1995 12:27 PM 

To: 'tor' 

Cc: 'dickson'; 'euterpe' 

Subject: Re: Cerberus octlet 6 


On Mnemosyne, and I assume Calliope as well, the part was to stay in reset or clear until 
the corresponding bit was explicitly cleared (set to zero) . Clearly, Euterpe must 
automatically come out of reset and clear, and in such a case, the Cerberus bits should be 
cleared by the end of the operation. 

Craig 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Sandeep Nijhawan [sandeep@MicroUnity.com] 

Thursday, January 19, 1995 12:33 PM 

'euterpe@gaea' 


> > It is the act of 

> > writing to octlet 6 with one of these bots set that actually 

> > triggers the reset, not the static level of the bit. So would it 

> > make more sense if these bits always returned 0 on a read? 
> 

>Yes, it seems better to me to make them return always zero. 

Hmm. . . If these bits are always read as zero how do we distinguish reset from logic 
clear from machine check ? 

Currently the boot code looks at the reset bit in oct 6 and if it finds it set and 
the clear bit not set it assumes a power-on reset and so turns up the knobs and then sets 
the clear bit (while zeroing the reset bit) . 

The second time around it should find just the clear bit set and it simply 

zeros it and proceeds with the boot sequence. If both bits are zero it assumes a machine 
check (as per the TSA) . It uses the bits in oct 7 just to make sure the reset or logic 
clear has completed successfully. 

I don't see why having to make sure these bits are zero while writing to oct 6 is so 

bad. 


Sandeep 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, January 19, 1995 1:26 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/icc BOM 24 . 0 initiated by woody completed @ Thu Jan 19 
11:23:36 PST 1995 with exit status 0.. chip 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hchu (Herman Chu) 

Thursday, January 19, 1995 6:17 PM 

'tbe'; 'geert' 

'pandora'; 'hchu' 

Re: Euterpe module form factor 


> From geert Thu Jan 19 09:42:21 1995 

> Date: Thu, 19 Jan 1995 09:42:19 -0800 

> From: geert (Geert Rosseel) 

> To: hchu, tbe 

> Subject: Re: Euterpe module form factor 

> Cc : pandora 

> Content -Length: 253 

> 

> Our current power estimate for Cronus ( = CMOS Euterpe) is closer to 

> 100 W. We've changed to a 3.3 V process from a 5V process. 

■> 

> We will do our design so that it works for a junction temperature of 

> 127 degrees. 
> 

> Geert 


With the reduced power (from 15 0 watts to 100 watts) , relaxed junction temperature 
requirement and larger die size (I am using 10cm x 10cm in my calculations) . We can use 
the same new Eu heat sink design. We might be able to do better with the junction 
temperature than 127 deg C (I assume we are talking about deg C, not deg F) at the worst 
environmental conditions . 


Herman 
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From: vijay@MicroUnity.com 

Sent: Thursday, January 19, 1995 6:41 PM 

To: 'tbe@MicroUnity.com'; 'noel@MicroUnity.com'; 'dbulfer@MicroUnity.com' 

Cc: Vijay@MicroUnjty.com'; 'pandora@MicroUnity.com' 

Subject: Micropax availability 

Just found out about the avialabilty of the various positions and flavors on the Micropax 
connector . 

80 pin-- vertical thru hole, vert surface mount, straddle mount. 
100 pin-- vertical surface mount 
12 0 pin-- vertical surface mount 

160 pin-- vert thru hole, vert surface mount, straddle, right angle thru hole. 
2 00 pin-- vert surface mount, straddle mount, right angle thru hole. 
24 0 pin-- right angle through hole. 

Based on the above I propose the following: 

Use of the 160 pin surface mount for the Calliope modules-- this will provide enough extra 
pins for the low power 5V, -5V, 12V, -12V, etc. 

Use the 160 pin for the Euterpe [ according to jay tomlinson, this needs 

152 pins] . If this is not enough headroom, then the next step up would be the 200 pins. 
Opinions ? 

This brings us to the last problem, i.e. the mnemo modules. Presently we are talking 
about using the 8 0 pin micropax-- is this enough ? The next step up would be the 160 pin. 
Opinions on this ? 
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Subject: 


Sent: 

To: 

Cc: 


From: 


rich (Rich McCauley) 

Thursday, January 19, 1995 6:44 PM 

'graham'; 'tbr' 

'pandora' 

Re: CMOS clocks 


> From tbr Wed Jan 18 17:16:33 1995 

> Date: Wed, 18 Jan 1995 17:16:27 -0800 

> Prom: tbr (Tim B. Robinson) 

> To: graham (Graham Y. Mostyn) 

> Cc : pandora, rich 

> Subject: Re: CMOS clocks 

> Content- Length: 74 0 


> Graham Y. Mostyn wrote (on Wed Jan 18) : 
> 

> I also agree with this approach. I would point out, however, that 
Tim' s 

> suggestion about use of Calliope as a reference clock source is 
undesirable, 

> since digital -only Pandora systems may not require Calliope to 
provide I/O. 

> Separate clock arrangements would then have to be made for the CMOS 

> Euterpe . 

> 

> We are making provision for a separate 54MHz reference when there is 

> no Calliope. Hoever, if there is a Calliope, it's essential we can 

> run everything from a single reference or the Hermes channels will not 

> function. Assumeing we still want the cleanest possible clock to 

> Calliope, we must then be able to generate the CMOS euterpe clock from 

> the 54MHz Calliope output. 


Or, alternatively, we could provide an external divide by circuit which takes as it's 
input the 1080Mhz clock directly. This may be too restrictive though, because it could 
only generate 1080/n. 


> 


> Tim 


> 


rich 
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From: craig 

Sent: Thursday, January 19, 1995 6:56 PM 

To: 'geert hchu tbe' 

Cc: 'pandora' 

Subject: Re: Euterpe module form factor 

10 cm x 10 cm sounds like an awfully big die. 
Craig 
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From: craig (Craig Hansen) 

Sent: Thursday, January 19, 1995 7:56 PM 

To: 'geert'; 'fichu'; 'tbe' 

Cc: 'pandora' 

Subject: Re: Euterpe module form factor 

10 cm x 10 cm sounds like an awfully big die. 
Craig 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Thursday, January 19, 1995 8:38 PM 


'craig (Craig Hansen)' 
'dickson'; 'euterpe' 


Subject: 


Re: Cerberus octlet 6 


Craig Hansen wrote (on Thu Jan 19) : 

On Mnemosyne, and I assume Calliope as well, the part was to stay 
in reset or clear until the corresponding bit was explicitly cleared 
(set to zero) . Clearly, Euterpe must automatically come out of reset 
and clear, and in such a case, the Cerberus bits should be cleared 
by the end of the operation. 

Aha, that explains the confusion. I believe it is the case that Mnemosyne and Calliope 
behave that way, and of course Euterpe comes out autonomously. Now, given we have the 
bits in octlet 7 which show the actual state of reset completion, is it acceptable to just 
make the bits in octlet 6 read 0? That's a simple fix I think. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, January 19, 1995 11:03 PM 

'hchu (Herman Chu)' 

'geert'; 'hchu'; 'pandora'; 'tbe' 

Re: Euterpe module form factor 


Herman Chu wrote (on Thu Jan 19) : 


With the reduced power (from 150 watts to 100 watts), relaxed junction 
temperature requirement and larger die size (I am using 10cm x 10cm in my 

Hey when did we go to wafer scale integration! Assume a square die of 3sq cm area. 

calculations) , We can use the same new Eu heat sink design. We might be able 

to do better with the junction temperature than 127 deg C (I assume 

we are talking about deg C, not deg F) at the worst environmental conditions . 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, January 1 9, 1 995 1 1 :09 PM 

To: Vijay@MicroUnity.com' 

Cc: 'dbulfer'; 'noef; 'pandora'; 'toe'; Vijay' 

Subject: Micropax availability 


vijay@MicroUnity.com wrote (on Thu Jan 19) : 

Just found out about the avialabilty of the various positions and flavors 
on the Micropax connector. 

8 0 pin-- vertical thru hole, vert surface mount, straddle mount. 
10 0 pin-- vertical surface mount 
12 0 pin-- vertical surface mount 

160 pin-- vert thru hole, vert surface mount, straddle, right angle thru hole. 
20 0 pin-- vert surface mount, straddle mount, right angle thru hole, 
24 0 pin-- right angle through hole. 

Based on the above I propose the following: 

Use of the 160 pin surface mount for the Calliope modules-- this will 
provide enough extra pins for the low power 5V, -5V, 12V, -12V, etc. 

Use the 160 pin for the Euterpe [ according to jay tomlinson, this needs 
152 pins] . If this is not enough headroom, then the next step up would be 
the 200 pins. Opinions ? 

This brings us to the last problem, i.e. the mnemo modules. Presently we 
are talking about using the 80 pin micropax-- is this enough ? The next 
step up would be the 160 pin. Opinions on this ? 

We should be trying to make the mnemo and calliope slots as generic as possible to allow 
for the possibility of different configurations in the future. 80 pins is fine for 
Mnemosyne, and 160 is fine for Euterpe. 80 would be fine for Calliope except for the 
requirement for auxilliary supplies. Given that there is no way we can bring the 3.3 in 
through the same connector, is there a possible solution which combines the auxilliary 
power with the main 3 . 3V power rather than with the signal connector? If so we can then 
keep the signal connector identical between Mnemosyne and Calliope. 

Tim 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Friday, January 20, 1995 12:15AM 

■geert (Geert Rosseel)'; 'billz (Bill Zuravleff)' 

output of euterpe/verilog/bsrc/nb/.checkoutrc (fwd) 


Buffalo Chip writes: 

From chip Thu Jan 19 23:03:07 1995 
Date: Thu, 19 Jan 1995 23:00:22 -0800 
From: chip (Buffalo Chip) 

Message- Id: <19 95 012 00700 .XAA15883@tomato.microunity . com> 
To : hopper 

Subject: output of euterpe/verilog/bsrc/nb/ . checkoutrc 

The output from euterpe/verilog/bsrc/nb/ . checkoutrc is 1952k, so it is not included 
in this mail message. Instead, check the file 

/n/tmp/chiplog/hopper. tomato. 15343 . euterpe-verilog-bsrc~nb 

(which is accessible from all machines) . This file will disappear in 
about 5 days . 

By the way, the exit status returned by .checkoutrc was 0. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, January 20, 1995 8:14 AM 

'tbe (Tom Eich)' 

'Graham Y. Mostyn'; 'pandora' 

Re: Mixed-signal module power 


Tom Eich wrote {on Fri Jan 20) : 


On Thursday, January 19, Graham Mostyn wrote: 

> Tom, I've reviewed Noel's first estimate on the Pandora 

> mixed- signal module power consumption, which is based on the 

> power requirement to Hestia, of 67W (Calliope) + 35W (discretes) . 
> 

> On account of the limited functionality and simpler design of 

> the modules, they will actually consume much less; we estimate 

> 67W (Calliope) + 4W (discrete) = 71W. 


Last I heard, Calliope was 54. 9W nominal. What is the rationale 
behind the 67W number? We need steady- state nominal and worst - 
case numbers for all dissipators for thermal analysis. 

As far as I know it is still 54.9. 67 may be a typo, for a long time that was the 
estimate for Euterpe. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Friday, January 20, 1995 1 1 :03 AM 

To: 'brianP; 'torn' 

Cc: 'geert' 

Subject: snapshot make 


I died about a half an hour ago: 

Deal exiting with status 1 

gmake [2] : *** [do-mlobe- time] Error 1 

gmake [2] : Leaving directory 

*" /N/auspex/root /s23 /euterpe -proteus - cp/ leaf gen 1 
gmake [1]: *** [all] Error 1 
gmake [1] : Leaving directory 

VN/auspex/root/s2 3/euterpe-proteus-cp/leafgen' 
gmake: *** [proteusmake] Error 1 

Can you check what went wrong please? (The log is in makerrs2) . 
Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


brianl (Brian Lee) 

Friday, January 20, 1 995 1 1 : 1 3 AM 
Tim B. Robinson* 

'torn (Thomas Laidig)'; 'geert (Geert Rosseel)' 
Re: snapshot make 


Tim B . Robinson writes: 
I died about a half an hour ago: 

Deal exiting with status 1 

gmake [2] : *** [do-mlobe- time] Error 1 

gmake[2]: Leaving directory 
- /N/auspex/root /s23 /euterpe-proteus- cp/ leaf gen ' 
| gmake [1] : *** [all] Error 1 
j gmake [1] : Leaving directory 

" /N/auspex/root /s23 /euterpe-proteus- cp/leaf gen' 
| gmake: *** [proteusmake] Error 1 

{Can you check what went wrong please? (The log is in makerrs2) . 

Two lobes failed because of stale NFS file handles for tt2wave. You can restart it and it 
will re-do those two that failed and then continue. 


Brian L. 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Jeff Marr [jeffm@MicroUnity.com] 

Friday, January 20, 1995 11:19 AM 

'euterpe@gaea' 


In article <199501200238 , SAA04 659@aphrodite .microunity . com>, 
tbr@gaea.microunity.com (Tim B. Robinson) writes: 
> 

> Craig Hansen wrote (on Thu Jan 19) : 
> 

> On Mnemosyne, and I assume Calliope as well, the part was to stay 

> in reset or clear until the corresponding bit was explicitly cleared 

> (set to zero) . Clearly, Euterpe must automatically come out of reset 

> and clear, and in such a case, the Cerberus bits should be cleared 

> by the end of the operation. 
> 

> Aha, that explains the confusion. I believe it is the case that 

> Mnemosyne and Calliope behave that way, and of course Euterpe comes 

> out autonomously. Now, given we have the bits in octlet 7 which show 

> the actual state of reset completion, is it acceptable to just make 

> the bits in octlet 6 read 0? That's a simple fix I think. 
> 

> Tim 


Is it the intention that a boot program can determine the restart reason entirely from the 
contents of octlet 7? 

I do not see how a program can tell the difference between a normal reset and a program 
invoked clear. The boot SW needs to know that. I suppose it can surmise from the deferred 
write bit in octlet 6 that it was a clear. 

Am I missing something here? 


Jeff Marr 
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From: graham (Graham Y. Mostyn) 

Sent: Friday, January 20, 1995 1 1:25 AM 

To: 'tbe'; 'tbr' 

Cc: 'graham@MicroUnity.com'; 'pandora' 

Subject: Re: Mixed-signal module power 


Actually I focus sed on the board level consumption, and copied the Calliope consumption 
from Noel's spec, 2 OA at 3.3V = 66W. 

My mistake not to verify that too. Nothing has changed on Calliope! 
Graham . 

> From tbr Fri Jan 20 06:14:16 1995 

> Date: Fri, 20 Jan 1995 06:13:55 -0800 

> From: tbr (Tim B. Robinson) 

> To: tbe (Tom Eich) 

> Cc: graham@MicroUnity.com (Graham Y. Mostyn) , pandora 

> Subject: Re: Mixed-signal module power 

> Content -Length: 779 


> Tom Eich wrote (on Fri Jan 20) : 


> On Thursday, January 19, Graham Mostyn wrote: 
> 

> > Tom, I've reviewed Noel's first estimate on the Pandora 

> > mixed- signal module power consumption, which is based on the 

> > power requirement to Hestia, of 67W (Calliope) + 35W (discretes) . 

> > 

> > On account of the limited functionality and simpler design of 

> > the modules, they will actually consume much less; we estimate 

> > 67W (Calliope) + 4W (discrete) = 71W. 


> Last I heard. Calliope was 54 . 9W nominal. What is the rationale 

> behind the 67W number? We need steady- state nominal and worst - 

> case numbers for all dissipators for thermal analysis. 
> 

> As far as I know it is still 54.9. 67 may be a typo, for a long time 

> that was the estimate for Euterpe. 
> 

> Tim 
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From: age (Alan Corry) 

Sent: Friday, January 20, 1 995 1 1 :37 AM 

To: 'Graham Y. Mostyn' 

Cc: 'tbe (Tom Eich)'; 'tbr (Tim B. Robinson)'; 'graham@MicroUnity.com'; 'pandora' 

Subject: Re: Mixed-signal module power 


> Actually I focussed on the board level consumption, and copied the 

> Calliope consumption from Noel's spec, 20A at 3.3V = 66W. 

> My mistake not to verify that too. Nothing has changed on Calliope! 
> 

> Graham . 

I would point out that there are changes pending. In particular we are committed to adding 
additional atoms for : 

Receiver IQ Balancer (~5000 additional per receiver) 
up bus interface (TBD) 

to the first rev of Calliope. I'd probably add about 2W to the Calliope number. 

> > From tbr Fri Jan 2 0 06:14:16 1995 

> > Date: Fri, 20 Jan 1995 06:13:55 -0800 

> > From: tbr (Tim B. Robinson} 

> > To: tbe (Tom Eich) 

> > Cc: graham@MicroUnity.com (Graham Y. Mostyn), pandora 

> > Subject: Re: Mixed- signal module power 

> > Content -Length: 779 

> > 

> > 

> > Tom Eich wrote (on Fri Jan 20) : 

> > 

> > 

> > On Thursday, January 19, Graham Mostyn wrote: 

> > 

> > > Tom, I've reviewed Noel's first estimate on the Pandora 

> > > mixed- signal module power consumption, which is based on the 

> > > power requirement to Hestia, of 67W (Calliope) + 35W (discretes) . 

> > > 

> > > On account of the limited functionality and simpler design of 

> > > the modules, they will actually consume much less; we estimate 

> > > 67W (Calliope) + 4W (discrete) = 71W. 

> > > 

> > 

> > Last I heard, Calliope was 54 . 9W nominal. What is the rationale 

> > behind the 67W number? We need steady- state nominal and worst - 

> > case numbers for all dissipators for thermal analysis . 

> > 

> > As far as I know it is still 54.9. 67 may be a typo, for a long 

> > time that was the estimate for Euterpe. 

> > 

> > Tim 

> > 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Friday, January 20, 1995 1 1 :47 AM 
lisa' 

Current failure of terp 


Well, now it's once again failing in dlws_get_next_line+ll4 8 . It get's a machine check 
with an illegal instruction. The value of $pc certainly seems to decode as a valid, legal 
instruction. 

I trust that if you repeat my steps you should see the same behavior. My hands are off 
this stuff for the time being. 

You're best to try running it in ~gregg/stb/apps/tv directly to eliminate any other 
sources of error (maybe you should even run it as me : - ) . 

Note that handle- >cur line == 4, indicating that the routine's only been entered a couple 
of times. 

The only thing interesting about this particular place in the code is that we've just 
started up two calliope event handlers (video-out and audio-out) . 

Here's the contents of my screen: 

gregg hts ( 688 ) : ~/stb/apps/tv> /a/sof t/stb/bin/tgdb kernel GDB is free software and you are 
welcome to distribute copies of it under certain conditions; type "show copying" to see 
the conditions. 

There is absolutely no warranty for GDB; type "show warranty" for details. 

GDB 4.12.86 (mips- sgi- irix5 --target terp-stb) , Copyright 1994 Free Software Foundation, 

Inc . . . 

Breakpoint 1 at 0x200000000160 
Connected to the simulator. 
0x200000000160 in last_real () 

Breakpoint 2 at Oxfff 0000000004628 : file trap.c, line 231. 
Breakpoint 3 at Oxfff 0000000003704 : file task.c, line 627. 
[Switching to thread 2 (cylinder 2) ] 

Breakpoint 3, task_switch (task=0xf f f f f f f f f f f f f f f f ) at task.c: 627 
627 int curcyl = CURRENT_CYL ; 

Oxfff 0000000008194 in task_loader () at taskload. c : 90 
90 task switch (task) ; 

Breakpoint 4 at 0x8 0 0 04c: file tv_main.c, line 71. 
Breakpoint 5 at 0x8l2be8 

Breakpoint 6 at 0x8l2alc: file assert. c, line 9. 
[Switching to thread 1 (cylinder 1)] 

Breakpoint 4, main () at tv_main.c:71 

71 tv_thread_id = threadCreate (&sched_params, (void *)tv_stack, 

(gdb) c 
Continuing . 

0.670570 ms(ao=0):N0 SIGNAL: wait for message 
0.920687 ms (ao=0) :ACQUIRE PAT: wait for PAT 
0.981548 ms (ao=0) :ACQUIRE PAT: new PMT PID 2 
1.027178 ms (ao=0> :ACQUIRE PMT: wait for video PID 
1.068048 ms (ao=0) : ACQUIRE PMT: new video PID 16 
1.115131 ms(ao=0) : INIT VIDEO: decode video 
55.626957 ms (ao=0 ) : INIT VIDEO: Initialize DLWS 

56.252281 ms (ao=0 ) : INIT VIDEO: presentation s/e ( 0 . 000000/0 . 000000 ) 
56.322067 ms (ao=0 ) : INIT AUDIO: audio PID 17 
56.384594 ms (ao=0 ): SECOND VIDEO: decode video 

78.213699 ms (ao=0 ): START DLWS: active video start @101. 651956 78.373970 ms (ao=0) : START 
AUDIO: run to acquire at 101.651956 

80.050102 ms (ao=96) : START AUDIO: enable audio at 110.363067 
80.170807 ms (ao=96) : AWAIT AUDIO: wait until 93.301841 
80.314018 ras (ao=96) : DECODE PSI: decode PSI 
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80.417145 ms (ao=96) : FRAME SYNC : dlws_next s/e (101.651956/135.018622) 

80.514145 ms (ao= 96) : FRAME SYNC: receiveMessage 93.321320 ms (ao= 96) : DECODE AUDIO: decode 
audio frame 

94.919273 ms (ao=192 ): AWAIT AUDIO: wait until 101.986878 Cylinder 4 got exception 8 while 
in interrupt mode. 


PC 

= 

Oxf f f 0800000c04 7a8 




rOO 


Oxf f f 0800000c02e90 

rOl 

= 

Oxf f f 0800000801f f 0 

r02 


Oxf ff 080000080473 0 

r03 

= 

Oxf ff 0800000802940 

r04 


0x00000000000005 0 0 

r05 


Oxf f f 0800000802C00 

r06 

= 

0x0 0 04bl4 00 0 05e24 0 

r07 

= 

0x0004bl400005dd40 

r08 

— 

0x000000000000000 0 

r09 

= 

Oxf f f 0800000802ec0 

rlO 


0x0 000000000000040 

rll 


0x0000000000000280 

rl2 

— 

0x00 00000000000280 

rl3 


0x0000000000000281 

rl4 

= 

0x0 0 00000000000004 

rl5 

= 

0x0000000000000001 

rl6 


0x0 0 00000000000002 

rl7 

- 

0x0000000000000003 

rl8 

— 

Oxf ff 9002808400000 

rl9 


0x0000000000008000 

r2 0 

- 

0x0 0 00000000000004 

r21 

= 

0x0000000000000000 

r22 

= 

Oxf f f 92 000000a4020 

r23 


0x00000000 0 0 000 010 

r24 

= 

Oxf f f f f f f f f f f f f f f f 

r2 5 


Oxf f f f f f f f f f f f f f f f 

r2 6 

- 

OxOOOOOOOOOOf f f f f f 

r27 


0x0000000000000007 

r2 8 

- 

0x0 0 000 OOOf f f f f f f f 

r2 9 


Oxf f f 92 00 000 0a4 03 0 

r3 0 

- 

OxOOOOOOOOOOOOOf f f 

r31 

- 

0x0000000000000000 

r32 


0x0 0 0 0000000000010 

r33 

- 

0x0 004bl4 00005e24 0 

r34 

= 

0x00 01000001020206 

r35 


0x0202020201010101 

r3 6 

- 

0x00 0 0000000000040 

r37 

- 

Oxf f f 08 00000802c0 0 

r3 8 

= 

0x00 04bl4 00005ed3e 

r39 

- 

0x0 0 000 000000002c0 

r4 0 

- 

0x00 0 00000005002c0 

r41 


0x47404 74047404740 

r42 

= 

0x00 0 0000000000000 

r4 3 

= 

0x0 000000000000000 

r44 

- 

0x00 0 0000000000000 

r4 5 

= 

Oxf ff 0800 000802c00 

r46 


Oxf f f f f f f f f f f f f f f f 

r4 7 


Oxf f f f f f f f f f f f f f f f 

r48 


Oxf ff 0800000803180 

r4 9 


Oxff f08000008034d0 

r50 


0x0004bl4 00005dd4 0 

r51 


Oxf ff 9002800001160 

r52 


OxOOOOOOOOOOOOOOcO 

r53 


Oxf ff 0800000802940 

r54 


0x8080808080808080 

r55 


0x8080808080808080 

r56 


0x0000000000000000 

r57 


0x0000000000000000 

r58 


OXOOOOOOOOOOOOOOOO 

r59 


0x0000000000000000 

r60 


OxOf Of Of Of Of OfOf Of 

r61 


OxOf Of Of Of Of Of Of Of 

r62 


0x0000000000000000 

r63 


0xfff0800000800880 


Machine check 

Program received signal SIGILL, Illegal instruction. 
[Switching to thread 4 (cylinder 4)] 

Type <return> to continue, or q <return> to quit 

Program received signal SIGILL, Illegal instruction. 

dlws_get_next_line (handle=0xfff 080000080473 0, buf=0xfff 0800000802940) 

at dlwsrt.c:204 
2 04 yh = *yptr++; 

(gdb) x/i $pc 

Oxf f f 0800000c047a8 <dlws_get_next_line+1148 > : 112Bli r40,r6,0 

(gdb) p/x $r6 

$1 - 0x4bl400005e240 

(gdb) x/i 0xfff0800000c047a8 

Oxf f f 0800000c047a8 <dlws_get_next_line+1148 > : 112811 r40,r6,0 
(gdb) p handle- > cur line 
$2 = 4 

(gdb) 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

2 55 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: hchu (Herman Chu) 

Sent: Friday, January 20, 1 995 1 1 :51 AM 

To: 'tbr'; 'geert'; 'tbe' 

Cc: 'pandora' 

Subject: Re: Euterpe module form factor 


Ok, I got it. The current die size estimate is 3 sq. cm. I meant 2 cm x 
2 cm 

before and not 10 cm x 10 cm. Sorry. 
Thank you. 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Bob Morgan [bobm@MicroUnity.com] 

Friday, January 20, 1 995 1 1 :55 AM 

'euterpe@gaea' 


Hi, 

I've released version 1.6 of the Euterpe MicroArchitecture guide. As always, you can type 
"gmake book" in the doc directory to print out your own copy, or let me know and I'll be 
happy to print out a bound copy for you. The list of changes in this version are in the 
back of the book. 

If you have any old versions of the book that you want to get rid of, I'd be happy to 
dispose of them for you. Just let me know. 

Also, as always, comments and suggestions are appreciated. 

Thanks , 

Bob 
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From: Sandeep Nijhawan [sandeep@dolphin] 
Sent: Friday, January 20, 1995 12:03 PM 
To: 'tbr@doIphin'; 'jeffm@dolphin' 
Subject: Cerberus Oct 6 


I posted this to muse.euterpe yesterday and I assumed it also gets 
sent to the euterpe mailing list since you folks probably don't read the 
newsgroups - 

>|> It is the act of 

>j> writing to octlet 6 with one of these bots set that actually triggers 
>j> the reset, not the static level of the bit. So would it make more 
>|> sense if these bits always returned 0 on a read? 

> 

>Yes, it seems better to me to make them return always zero. 

> 

Hmm... If these bits are always read as zero how do we distinguish 
reset from logic clear from machine check ? 

Currently the boot code looks at the reset bit in oct 6 and if it 
finds it set and the clear bit not set it assumes a power-on reset and so 
turns up the knobs and then sets the clear bit (while zeroing the reset bit). 
The second time around it should find just the clear bit set and it simply 
zeros it and proceeds with the boot sequence. If both bits are zero it assumes 
a machine check (as per the TSA). It uses the bits in oct 7 just to make sure 
the reset or logic clear has completed successfully. 

I don't see why having to make sure these bits are zero while writing 
to oct 6 is so bad. 

Sandeep 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday. January 20, 1995 4:41 PM 

To: 'geeiKgrhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 79,0 initiated by woody completed @ Fri Jan 20 
14:40:25 PST 1995 with exit status 2.. chip 
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From: 
Sent: 
To: 

Subject: 


lisar (Lisa Robinson) 

Friday, January 20, 1995 8:11 PM 

'tbr'; 'geert' 

spivs 


How do I make an Ivs net list? 
I tried lvsnet and got : 

gmake[l] : *** No rule to make target "euterpe-passl . spivs ■ . Stop. 
gmake[13: Leaving directory Vs2/euterpe/verilog/bsrc ' 
page queued 


Lisa R. 
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From: tbr (Tim B. Robinson) 

Sent: Friday, January 20, 1 995 1 1 :04 PM 

To: 'bobm (Bob Morgan)' 

Cc: 'veena'; 'craig' 

Subject: BIST bit 


Bob Morgan wrote (on Fri Jan 20) : 
Hi Tim, 

Can you tell me where the BIST bit is in mnemo's 
cerberus registers? 

Bit 61 in octlet 6 is defined as "selftest", so I think this is what should be used. 
Bit's 60:48 are then available to further control the tests. (I'm looking at my euterpe 
document to get this, but I beleive it is the same int he original Mnemosyne definition, 
though of course in the first version it was not implemented.) 

Now as far as I know, Craig's definition only allocates a single bit in octlet 7 (bit 62) 
to report the result, whereas the actual design reports much more and the proposal was to 
report an entire octlet 1 s worth of status. Craig, can you let bob know what preference 
you have for where to report this? : 


Octlet Bits 

X 63.. 50 

bist fail 

48. .33 
indicator of 

tests (1-16) 

31. .28 
pattern of 


16. 

individual 


01 


00 


field name def .value 

fail address 0 

bist test fail 0 

comparator fail state 0 
bist test enable Of 


(1-16) 
test (written to zero 
Tim 


test 


range interpretation 
0-3fff address of last 

0-ffff pass=0/fail=l 

individual bist 

0-f comparator fail 

last bist fail 
0-ffff enable bits=l for 

bist tests 

0-1 enables bist 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig (tail)) 

Saturday, January 21, 1995 12:49 PM 

'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)'; Vo (Tom Vo)'; 'brianl (Brian Lee)' 
'cadettes'; 'torn (Thomas Laidig)' 
new leafmold, etc. 


I think everything is ready to build the latest and greatest leaf cell layouts. I've 
checked in and released: 

a new version of vlsimm (including man page) that adds a notch_fill 
function for filling now- illegal metal notches and holes. Note 
that the current implementation is abysmally inefficient, but it 
works, certainly well enough for the xb cells, and I have some 
ideas for how to improve it later if /when required. 

the new lobe layouts needed to improve the output characteristics 
of the big or gates 

and (as a non-dot- zero version, so it didn't build in /u/chip) the 
changes to leafmold to make use of all this stuff, and also to save 
the previous layouts and wire-cap files (in the directories 
leaf gen/ leafmold/ { layout , wire -cap} -save) to help brianl or whomever 
analyze why the timing of some gate suddenly changed for no 
apparent reason 

As I understand it, we plan to run this stuff first in the snapshot, then, when we have 
the cpu cycles available, back-fill it into /u/chip. The above changes will cause a 
complete rebuild of all leaf cell layouts -- hopefully the last such before we tape out 
euterpe . 

I think I've tested this stuff pretty well in my local area, so I think it'll work (I 
checked that, as expected, no leaf cells changed size) . 

If anything 's needed, send me a page. . . I'll be out on the bay most of the rest of the day 
today, but I'll get to it as soon as I can this evening. 


V 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 21, 1995 12:59 PM 

'torn (Tom Laidig (tau))' 

'brianl (Brian Lee)'; 'cadettes'; 'geert (Geert Rosseel)'; 'torn (Thomas Laidig)'; Vo (Tom Vo)' 
new leafmold, etc. 


tau wrote (on Sat Jan 21) : 

I think everything is ready to build the latest and greatest leaf cell 
layouts. I've checked in and released: 

a new version of vlsimm (including man page) that adds a notch_fill 
function for filling now-illegal metal notches and holes. Note 
that the current implementation is abysmally inefficient, but it 
works, certainly well enough for the xb cells, and I have some 
ideas for how to improve it later if /when required. 

the new lobe layouts needed to improve the output characteristics 
of the big or gates 

and (as a non-dot- zero version, so it didn't build in /u/chip) the 
changes to leafmold to make use of all this stuff, and also to save 
the previous layouts and wire -cap files (in the directories 
leaf gen/ leafmold/ { layout , wire- cap} -save) to help brianl or whomever 
analyze why the timing of some gate suddenly changed for no 
apparent reason 

As I understand it, we plan to run this stuff first in the snapshot, 
then, when we have the cpu cycles available, back-fill it into 
/u/chip. The above changes will cause a complete rebuild of all leaf 
cell layouts -- hopefully the last such before we tape out euterpe. 

I think I've tested this stuff pretty well in my local area, so I think 
it'll work (I checked that, as expected, no leaf cells changed size). 
If anything 's needed, send me a page. . . I ' 11 be out on the bay most of 
the rest of the day today, but I'll get to it as soon as I can this 
evening . 

I'll pick it up now. The last version had died again and I'm waiting for brian's post 
mortem, but I may as well get the new run started. I did notice a few layout checkins 
which have not been released. Are these relevant? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig (tau)) 

Saturday, January 21, 1995 1:04 PM 

'Tim B. Robinson' 

'brianl (Brian Lee)'; 'cadettes'; 'geert (Geert Rosseel)'; 'vo (Tom Vo)'; 'tau' 
Re: new leafmold, etc. 


Tim B. Robinson writes: 

tau wrote (on Sat Jan 21) : 

As I understand it, we plan to run this stuff first in the snapshot, 
then, when we have the cpu cycles available, back-fill it into 
/u/chip. The above changes will cause a complete rebuild of all leaf 
cell layouts -- hopefully the last such before we tape out euterpe. 

I think I've tested this stuff pretty well in my local area, so I 
think 

it'll work (I checked that, as expected, no leaf cells changed size). 
If anything *s needed, send me a page... I'll be out on the bay most of 
the rest of the day today, but I'll get to it as soon as I can this 
evening . 

I'll pick it up now. The last version had died again and I'm waiting 
for brian's post mortem, but I may as well get the new run started. I 
did notice a few layout checkins which have not been released. Are 
these relevant? 

Sounds good. Any unreleased layout checkins should be irrelevant. 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, January 21 , 1995 10:24 PM 

To: 'stick'; 'bpw' 

Cc: 'geert'; 'torn' 

Subject: ged/ca BOM 


In updating the proteus snapshot for euterpe I notice we do not have a .0 BOM in 
proteus/ged/ca. Should there be a release there? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, January 22, 1995 12:06 AM 

'craig (Craig Hansen)' 

'euterpe'; 'mws' 

Re: EUTERPE WORKING: SMux64 not to be supported 


Craig Hansen wrote (on Mon Jan 16) : 

smux is also useful for writing a subset of the bits of an octlet, as 
may occur in modifying a bit field in a structure. smux also permits 
(but obviously does not require) a much faster implementation, as it 
doesn't modify reg state and can therefore be performed with timing of 
stores; i.e. it can be buff erred. 

It seems foolish to me to nuke the instruction just to avoid fixing a bug. 

It would be nice to fix it, I agree, but mark thinks the fix is non- trivial and since the 
software group have said they don't need it we have it at the bottom of the priority list 
at present . 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@MicroUnity.com] 
Sunday, January 22, 1995 12:34 AM 
'tbr@MicroUnity.com' 

Craig Hansen; 'euterpe@MicroUnity.com'; 'mws@MicroUnity.com' 
Re: EUTERPE WORKING: SMux64 not to be supported 


Tim Robinson wrote (on Sat Jan 21) : 

Craig Hansen wrote (on Mon Jan 16) : 

smux is also useful for writing a subset of the bits of an octlet, as 
may occur in modifying a bit field in a structure. smux also permits 
(but obviously does not require) a much faster implementation, as it 
doesn't modify reg state and can therefore be performed with timing of 
stores; i.e. it can be buff erred. 

It seems foolish to me to nuke the instruction just to avoid fixing a bug. 

It would be nice to fix it, I agree, but mark thinks the fix is 
non-trivial and since the software group have said they don't need it 
we have it at the bottom of the priority list at present. 

Perhaps I should say why software says they don't need it... 

smux is a subset of smas -- both write a subset of the bits of an octlet, smas also writes 
a destination register while smux doesn't. 

So smas handles our needs it's easy enough to ignore the result in the register. As to 
the faster implementation, mark isn't taking it out of the architecture, just out of this 
implementation, where it wouldn't have been faster anyway. 


- Curtis 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, January 22, 1995 12:11 PM 

'fwo' 

'dickson'; 'geert' 
csyn run 


I made an spivs netlist from BOM 205.0 for lisar to convert to edif for logic 
verification. However, I decided to run csyn since I had it. Ther result is in 
~tbr/euterpe/verilog/bsrc/euterpe-passl . csyn 

(I used the ' lvsnet' target to get this) . I was rather surprised to see > 2MB of output. 
Canyou take a look please? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, January 22, 1995 1:00 PM 

'lisar (Lisa Robinson)' 

'geert* 

spivs 


Lisa Robinson wrote (on Fri Jan 20) : 


How do I make an lvs net list? 
I tried Ivsnet and got : 

gmake[l]: *** No rule to make target "euterpe-passl . spivs 1 . Stop, 
gmakejl]: Leaving directory "/s2/euterpe/verilog/bsrc ' 
page queued 

I checked in a Makefile change and was able to build it with the 'Ivsnet' target. The 
change was just to make the v2e step use the beavioral gtlb and register file to speed up 
the compilation. 

After making sure I had made ckgards in the ck section I ran 
gmake GARDS_SUBDIRS_l=ck GARDS_SUBDIRS_2= Ivsnet 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


fwo (Fred Obermeier) 

Monday, January 23, 1995 3:00 AM 

tbr' 

'dickson'; 'fwo'; 'geert' 
Re: csyn run 


Tim, 


The current released version of csyn and its rules is out of date. 

I haven't done a releasebom yet since the differential input swing check tests is not 100% 
correct yet. However, I have made other fixes to things like Exclusive input swing 
checks. The original test cases provided to me for the exclusive input swing checks was 
not right. 

Therefore, neither are the released set of rules. I still don't think the exclusive 
checks are right yet. 

Most of the errors in your csyn run refer to a fix I made to properly handle Iogic0_ab0pf . 
This gets mapped into logicl_abnd0pf . 

I have fixed the logicO/logicl errors in my local copy too. 

Looks like your spivs deck also has quite a few floating inputs. 

These inputs also cause ADRS errors. The output shorts may be real problems. 

Do you think I should release my incomplete but better version of csyn/celltest? 

My csyn runs looks a bit better: 

~/chip.bsrc/euterpe/verilog/bsrc/tbr_euterpe-passl .csyn 


Fred. 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Monday, January 23, 1995 10:45 AM 


Subject: 


'fwo (Fred Obermeier)' 
'dickson'; 'fwo'; 'geert' 
Re: csyn run 


Fred Obermeier wrote (on Mon Jan 23) : 


Tim, 


The current released version of csyn and its rules is out of date. 
I haven't done a releasebom yet since the differential input swing 
check tests is not 100% correct yet. However, I have made other fixes 
to things like Exclusive input swing checks . The original test cases 
provided to me for the exclusive input swing checks was not right. 
Therefore, neither are the released set of rules. I still don't 
think the exclusive checks are right yet. 

Most of the errors in your csyn run refer to a fix I made to properly 

handle Iogic0_ab0pf . This gets mapped into logicl_abndOpf . 

I have fixed the logicO/logicl errors in my local copy too. 

Looks like your spivs deck also has quite a few floating inputs. 

These inputs also cause ADRS errors. The output shorts may be real problems. 

Do you think I should release my incomplete but better version of csyn/celltest? 

I think it would be wort he a release, otherwise someone may waste some time on propblems 
you have already fixed. 

My csyn runs looks a bit better: 

-/chip. bsrc/euterpe/verilog/bsrc/ tbr euterpe-passl . csyn 

Thanks. I'll leave you to interpret the results as you have been doing and to post the 
analysis . 


Tim 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Monday, January 23, 1995 11:07 AM 

'geert' 

Re: Euterpe 


> Did you get my latest version ? Can you let me know . . I am ready to 
>build the next one . . 

Yes, I did pick it up yesterday after I got your page. I ran a linesearch 
route last night, and it did get better in several places. I'm going to 
investigate in more detail today, particularly the left corridor. 

Go ahead and build the next one. 


Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


stick (Bruce Bateman) 

Monday, January 23, 1995 11:30 AM 

'bpw'; 'tor' 

'geert'; 'torn' 

Re: ged/ca BOM 


> Date: Sat, 21 Jan 1995 20:23:31 -0800 

> From: tbr (Tim B. Robinson) 

> To: stick, bpw 

> cc: geert, torn 

> Subject: ged/ca BOM 


> In updating the proteus snapshot for euterpe I notice we do not have a 

> .0 BOM in proteus/ged/ca. Should there be a release there? 


I thought we ' d done a release there quite some time ago . I see not reason not to go ahead 
and do one if you need it. Any schematic activity there is long ago completed. 


> 


> Tim 


BB 
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From: 
Sent: 
To: 

Cc: 

Subject: 


tbr (Tim B. Robinson) 

Monday, January 23, 1995 11:41 AM 

'stick (Bruce Bateman) 1 

'bpw'; 'geeif; 'torn' 

Re: ged/ca BOM 


Bruce Bateman wrote (on Mon Jan 23) : 

> Date: Sat, 21 Jan 1995 20:23:31 -0800 

> From: tbr (Tim B. Robinson) 

> To: stick, bpw 

> cc : geert, torn 

> Subject: ged/ca BOM 


> In updating the proteus snapshot for euterpe I notice we do not have a 

> .0 BOM in proteus/ged/ca . Should there be a release there? 


I thought we'd done a release there quite some time ago. I see 
not reason not to go ahead and do one if you need it . Any- 
schematic activity there is long ago completed. 

Here 1 s the log of things not released at the ca level : 


revision 10.8 

date: 1994/11/08 16:23:07 LT; 
proteus/ged/ca/cawrpre4 

Added mbypre_ layout_equiv 

revision 10.7 

date: 1994/11/08 16:21:36 LT; 
proteus /ged/ ca/cawrpre2 

Added mbypre_ layout_equiv 

revision 10.6 

date: 1994/11/02 15:24:38 LT; 
proteus/ged/ ca/ caxldrv 

Added layout_equiv 

revision 10.5 

date: 1994/11/02 15:23:15 LT; 
proteus /ged/ ca/cainvbv3 

Added layout_equiv 

revision 10.4 

date: 1994/11/02 15:21:51 LT; 
proteus/ged/ ca/cabicx4 

Added layout_equiv 

revision 10.3 

date: 1994/10/31 16:22:49 LT; 
proteus /ged/ ca/cainvbv4 

Added cainvbv4t layout_equiv . 


author: bpw; state: Exp; lines: +2 -2 Release Target: 


author: bpw; state: Exp; lines: +2 -2 Release Target: 


author: bpw,- state: Exp; lines: +2 -2 Release Target: 


author: bpw; state: Exp; lines: +2 -2 Release Target: 


author: bpw; state: Exp; lines: +2 -2 Release Target: 


author: bpw; state: Exp; lines: +2 -2 Release Target: 
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revision 10.2 

date: 1994/10/27 14:26:43 LT; author 
proteus/ged/ca/cainvbv5 

Added parasitic=true to caps, verilog: 


revision 10. l 

date: 1994/10/27 14:25:17 LT; author 
proteus/ged/ca/cainvbv4 

Added parasitic=true to caps, verilog= 

] 

I'll go ahead and release it. 


Tim 


Stick; state: Exp; lines: +2 -2 Release Target: 
& layout_equiv= to sheets. 

stick; state: Exp; lines: +2 -2 Release Target: 
& layout_equiv= to sheets. 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Monday, January 23, 1995 7:01 PM 
'geert' 
netcap file 


Hi, 


My linesearch result reached this state of completion: 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 98.29% 
TOTAL CONNECTIONS LEFT UNROUTED = 4 58 5 

I've produced a netcap file for this result; it can be found in: 

/n/rhodan/s2 /wampler/ euroute/geert_euterpe- iter . netcap 

also, the file "unconnected.net" in the same directory is the list of all nets that were 
incompletely routed at the end of linesearch routing. 

I'll fire up a maze routing pass tonight. 


- Kurt 
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Sent: 

To: 

Cc: 


Subject: 


From: 


wayne (Wayne Freitas) 

Monday, January 23, 1995 8:29 PM 

'tor'; 'lisar'; 'graham'; 'jt'; 'mudge'; 'doi' 

'hestia'; 'wayne' 

HW Bring-up meeting minutes 


Attendees: tbr, doi, jr, graham, lisar, rmm, bill, arya, tbe, philip 

Reviewed main board testing status: 

-RF section, Arya and Rick have checked out the input of the RF section upto 
the LNA's. There was an Isolation problem on one of the relays which is 
probably due to the PCB layout. This will be looked at in the coming week, 
along with the Baluns, and filters. 

-Power section, -Sense input on DC-DC Module was shorted to 3,3V plane 

so that when the shorting resistors were installed there was a 1 ohm path to 
ground. In addition, further tests need to be performed to find out why there was 
-30 deg thermal delta with only 3 . 5amps on the 3.3V near the DC-DC Module 
and a -50 deg delta at a certain via close to Euterpe. 

Noel has not been able to perform any power subsystem tests due to his work 

on Pandora. Wayne to talk with Noel to see if someone can perform limited amount 

of tests for him until he's available. 

There was also a problem with the 12V input on the VCO shorting to the ground 
plane (this provided us with our first smoking Hestia) . Problem was caused by 
solder wicking under the component and shorting to the 12V input lead. Rick and 
Thuydo have indicated they will look into this. 

- Bill express concern on getting some noise measurements caused the SDRAM' s 

Graham, Bill, Yves, Arya and Rick to get together to review tests requirements. 
Wayne to set-up test jig and perform testing after data is provided. 

- Mechanical, mechanical test still in process, 3ea. boxes are available for noise 

and isolation tests. After mechanical tests are complete JR and Kien to tweak 
boxes and provide custom shielding for engineers when needed. 

- Philip and JR to generate prcedures for getting tkgnats bugs incorporated into 
rework instructions (engineering eco) for in-house use after Wayne provides 


-We postponed until next week going over the Calliope and Euterpe delivery dates 
and additional tests needing to be performed because I haven't updated the 
schedule to reflect the new delivery dates. 

Thats it folks, 


input . 
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From: billz (Bill Zuravleff) 

Sent: Tuesday, January 24, 1 995 1 1 :02 AM 

To: 'fwo'; 'hardheads' 

Subject: Re: More euterpe csyn reports. 


The cc errors -- cc_hz2or4backrl6 and cc_startrl6 being unconnected have been fixed and 
checked in. I'll release when I've got an updated placement. (All these messages from 2 
missconnects? These two are the only bugs I fixed.) 

Thanks , 
billz 
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From: Tom Eich [tbe@MicroUnity.com] 

Sent: Tuesday, January 24, 1 995 1:10PM 

To: 'boxers@M icroUnity.com'; 'dbulfer@MicroUnity.com' 

Cc: 'pandora@MicroUnity.com' 

Subject: Pandora open actions, can we close?? 


On 1/12, the (Tom Eich) wrote: 
Actions and status are as follows: 

>1) Noel to prepare a power spreadsheet with current by voltage per module or > lowest 
separable unit. 

Status; in progress. 

Can this be completed, please? The copy I have still has no fan load accounted for, and 
also has the incorrect Calliope module power (102W) that Graham corrected. 

>snip< 

Action: Philip and Noel to prepare power supply trade matrix. 
Done, I think. Philip and Noel, are you satisfied? 

Action: Noel to survey vendors and id candidate supplies. 
What is the status, please? 

>snip< 

>4) Noel and Vijay to id all signal and signal ground I/O lines for both the >Euterpe 
and Mnemo bricks >snip< 

Status: in progress; signal and signal ground requirements identified. 

Has an interconnect list or table been prepared? 

In another message, Jay Tomlinson requested p/ns for the connectors, has this been done? 

Action: Determine power requirements (ref . 1) above) and candidate power connectors and 
bus bars. 

What is the status? I am using the Eicon power connector for now, but believe there is an 
open question on Calliope module power I/O. 

>5) Noel to identify de- coupling cap requirements and tbe to include in area > 
calculations and layouts . 

Action: in progress. 

Can you please close this, Noel? 

>snip< 

>8) Herman to trade-off integral Mnemo fan vs. external system blower (s); tbe >and jt to 
support with layout concepts. 

Decision taken to pursue system level blowers for Mnemo modules and PCI cards as a first 
course, due to noise, size and power impact of individual module fans. 

Open action on material/finish for Mnemo heat sink. Can Herman, Vijay and tbe meet 
tomorrow at 2:00 to complete action? 

>snip< 
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Action: Noel and David to determine location and type of thermal protection in Pandora. 
Status? 

Discussed the PCI card containing the Mnemo and external Hermes port (for hestia, etc) . 
If this card conforms to the PCI mechanical standard, then this Mnemo will need a 
different heat sink than planned for the modules. 
Herman 

said this was possible, but needed to be assessed. 

Action: David raised concern relative to 3 . 3Vdc input if this is standard PCI card that 
could go in any slot. How to resolve? 

Action: Herman to determine feasibility of low profile heat sink and required flow rate. 

Let's discuss at the 2:00 tomorrow, Herman. 

>snip< 

Please respond via E-mail to the newsgroup to provide status and close these out. 
-Tom 


Tom Eich j tbe@microunity.com 

MicroUnity Systems Engineering, Inc. j 
255 Caspian Dr. Sunnyvale, CA 94 089 j 
(408)734-8100, (408)734-8136 fax j 


Exhibit CIO 


Page 275 of 356 


From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Tuesday, January 24, 1995 2:07 PM 

'geert' 

Maze routing result 


Hi, 


The maze routing pass just finished. Incompletely routed nets went from 
4,066 down to 1,832. The "netcap" file for this is: 

/n/ rhodan/s2 /wampler/ euroute/geert_euterpe- iter .maze .netcap 
and the list of unconnected nets is in: 

/n/ rhodan/s2 /wampler /euroute /unconnected . maze . net 
- Kurt 
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From: doi (Derek Iverson) 

Sent: Tuesday, January 24, 1 995 2:13 PM 

To: 'tor* 

Subject: vltree differences (use a very wide screen) 

> /n/auspex/s 1 5/tbr/euterpe/proteus/verilog/clib/dffiiq.v 

> /n/auspex/s 15/tbr/euterpe/proteus/verilog/clib/dlatchq.v 

/n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xbffdfBs. v 
| /n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xbffdf6s.v 
/n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xborff4df 1 2s. v 
| /n/auspex/s 1 5/tbr/euterpe/proteus/veri log/dxl ib/xborff4df8s . v 
/n/auspex/s 1 5/tbr/euterpe/proteus/veri log/dxl ib/xborff5dfBs.v 
| /n/auspex/s 1 5/tbr/euterpe/proteus/veri 1 og/dx 1 ib/xborff5df6s. v 
/n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xborff6df8s. v 
| /n/auspex/s 1 5/tbr/euterpe/proteus/veri log/dxl ib/xborfF6df 6s. v 

> /n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xborff7df6s.v 
/n/auspex/s 1 5/tbr/euterpe/proteus/verilog/dxlib/xborffb7df8s. v < 

vltree differences (use a very wide screen) 
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Subject: 


Sent: 

To: 

Cc: 


From: 


mws (Mark Semmelmeyer) 
Tuesday, January 24, 1995 2:26 PM 
•jeffm'; 'djc' 
'mws' 

Re: Ifetch Page size 


> From djc Tue Jan 24 09:50:35 1995 

> When I talked to mws about the page size a couple weeks ago, I came 

> away with the impression that even though all values were not 

> supported, they 
all 

> mapped to legal values. Is this correct? 

I think what I wanted to say was that all values greater than the minimum page size would 
be remapped silently by the hardware to the largest avail size not greater than the 
programmed size. I wanted to discourage use of sizes that would require remapping upward 
(sizes less than 64 bytes) . It may actually be true that the hardware will do this 
remapping, but I thought it was a risk for future implementations and would be bad to 
count on. Going with this, the 18jan95 revision of the euterpe microarch doc in the cerb 
reg section requires the N programmed to be at least 6 . 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Tuesday, January 24, 1995 3:08 PM 
'Brendan Eich' 

Re: gnu-tools/sim/terp cycles. c 


apps/tv does use cycle- counting, it just doesn't programatically enable/disable it. 

Lisa has a reproducable test- case for the tv problem and has been working on it for the 
last few days. The symptom seems to be that a register value gets changed in mid- 
execution. 

By the way, any thought on the tv-app failures (stable and current) relating to 
continuity- counter botches in mpeg2-in? I didn't notice these yesterday. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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Sent: 
To: 

Cc: 


From: 


fwo (Fred Obermeier) 
Tuesday, January 24, 1995 3:19 PM 


'geert'; 'ong'; 'wingard' 
•fwo' 


Subject: 


vy differential drivers? 


Drew, 


What should I do about the csyn errors relating to shorted differential drivers in 
eamemalrlwp6xla? Do we want to allow this? 

The conversions I had with my model user, Drew, indicated that such a case should not 
occur. I've included Warren in this e-mail since I think that this is in one of his 
blocks . 

If a csyn rule restricts the drivers to the same instance (*/), then the new instance 
checking code for Differential Input Swing checks will flag this as an error since it 
makes sure that one positive side matches every negative driver, and one of the negative 
drivers matches every positive driver. 

I've saved the last csyn results in 

/u/ f wo/chip . bsrc/euterpe/verilog/bsrc/OLDl 

so that I can check the next BOM. Csyn reports 

Dif f InputSwingCheck: drivers come from different insts. 
Differential outputs from several instances are shorted together. 

The vy qualifier delcaring rbl_abd0p8 5vy and rbl_abnd0p85vy as common emitter and 
collector outputs should allow these nets to have multiple drivers. The inputs are do 
_ad0p85vy and d0_and0p85vy . 

I'd like for Geert or Drew to confirm that either: 

1. we need a new kind of checking for vy drivers, or 

2. change the way we check same instance drivers in general, or 

3. that we should not allow this kind of connection and euterpe should change. 

What should I do? 


Thanks , 
Fred. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


age (Alan Corry) 

Tuesday, January 24, 1995 3:20 PM 
'David Buffer* 

'graham@MicroUnity.com'; 'tbe (Tom Eich)'; 'hchu (Herman Chu)'; 'pandora' 
Re: Mixed-signal module power 


> > 


> > No - in previous mail, I confirmed that the figure for Calliope is 
indeed 

> > still - 5SW. The 67W was an error. 

> > 

> > (Alan Corry has also pointed out that known metal changes on the 

> > next revision of Calliope will add to consumption by ~2 watts; 

> > however, 
since 

> > there are several unknowns in the next rev., I believe we should 
continue 

> > to budget dissipation for this rev. only, using the ~55W figure) 

> > 

> > Graham. 

> > 

> My guess is that 2 W is in the noise compared to 55W and all the 

> unknowns . But you bring up an interresting issue regarding future 

> versions. Is it possible for you to bound power consumption for 

> versions that might appear within the next couple of years? It may 

> help prevent re-engineering the system when Calliope II emerges. 


I would recommend that we at least use the 55W+2W number as the nominal power. The extra 
2W represents packing some of the existing design tighter to make room for extra 
functionality after that there's no more atoms on the chip. 

To add to the uncertainty it is known that Calliope's logic family wasn't as well 
characterized as Euterpe's so its likely that we'll need to turnup the knobs for some 
domains (if not all domains) . So we'd better be prepared for that since unlike Euterpe, we 
need to meet the design goal of 12 96MHz for the digital receivers' filters to operate 
correctly. 


> 


> David 


> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vijay@MicroUnity.com 

Tuesday, January 24, 1995 3:24 PM 

Tom EicfY 

'pandora@MjcroUnity.com' 

Re: Pandora open actions, can we close?? 


>On 1/12, tbe {Tom Eich) wrote: 

> >snip< 
> 

> >4) Noel and Vijay to id all signal and signal ground I/O lines for 

> >both 
the 

> >Euterpe and Mnemo bricks >snip< 
> 

> Status: in progress; signal and signal ground requirements identified. 
> 

>Has an interconnect list or table been prepared? 


Done. Will share at next meeting. 

>ln another message, Jay Tomlinson requested p/ns for the connectors, 
>has this been done? 

No. We are still discussing whether or not surface mount connectors are necessary. 
> 

> Action: Determine power requirements (ref . 1) above) and candidate 

> power connectors and bus bars. 

> 

>What is the status? I am using the Eicon power connector for now, but 
>believe there is an open question on Calliope module power I/O. 

The non availabilty of extra low power pins on the 80 pin micropax has us looking for 
other solutions. Two options currently pursuing are the Metral connector from Berg for 
the all the power voltages. The other option is a multipin connector from Eicon. As soon 
as we receive enough details on this a decision can be made. 
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From: noel (Noel Verbiest) 

Sent: Tuesday, January 24, 1 995 4:56 PM 

To: 'dbulfer@MicroUnity.com'; 'age' 

Cc: 'graham@MicroUnity.com'; 'toe'; 'hchu'; 'pandora' 

Subject: Re: Mixed-signal module power 


> From age Tue Jan 24 13:19:47 1995 

> From: age (Alan Corry) 

> Subject: Re: Mixed- signal module power 

> To: dbulfer@MicroUnity.com (David Bulfer) 

> Date: Tue, 24 Jan 95 13:19:35 PST 

> Cc: graham@MicroUnity.com, tbe (Tom Eich) , hchu (Herman Chu) , pandora 

> X-Mailer: ELM [version 2.3 PL11] 

> Content -Length: 14 00 
> 

> > 

> > > 

> > > No - in previous mail, I confirmed that the figure for Calliope is 
indeed 

> > > still - 55W. The 67W was an error. 

> > > 

> > > (Alan Corry has also pointed out that known metal changes on the 
next 

> > > revision of Calliope will add to consumption by ~2 watts; however, 
since 

> > > there are several unknowns in the next rev., I believe we should 
continue 

> > > to budget dissipation for this rev. only, using the ~55W figure) 

> > > 

> > > Graham. 

> > > 
> 

> > My guess is that 2 W is in the noise compared to 55W and all the 

> > unknowns. But you bring up an interresting issue regarding future 

> > versions. Is it possible for you to bound power consumption for 

> > versions that might appear within the next couple of years? It may 

> > help prevent re-engineering the system when Calliope II emerges. 

> > 

> > David 

> > 
> 

> I would recommend that we at least use the 55W+2W number as the 

> nominal power. The extra 2W represents packing some of the existing 

> design 
tighter 

> to make room for extra functionality after that there's no more atoms 

> on 
the 

> chip. 
> 

> To add to the uncertainty it is known that Calliope's logic family 
wasn't 

> as well characterized as Euterpe's so its likely that we'll need to 
turnup 

> the knobs for some domains (if not all domains) . So we ' d better be 
prepared 

> for that since unlike Euterpe, we need to meet the design goal of 
1296MHz 

> for the digital receivers' filters to operate correctly. 
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Any idea how much power is involved in turning up the knobs ? 
Your best guess will do. 
Thank you . 
Noel. x783 
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From: jeffm (Jeff Marr) 

Sent: Tuesday, January 24, 1995 5:43 PM 

To: 'lisaf; 'tbr' 

Subject: snoopy and ikos 

I have made the changes necessary to support snoopy on the ikos. 

This includes building snoop. o in iblib, as well as providing a 

snoop.vhdl. Also, I have locally made the changes to 

i euterpe wrap, tb 

i_euterpe_wrap.vhdl 

and euterpe_wrap.V 

I would really, really like the various wrapper files to be checked over 
before I check them in. They are in -jeffm/bsim/. 

Thanx, 
jeffin 
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Subject: 


Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Tuesday, January 24, 1995 6:49 PM 
'hestia' 
'graham' 

Hestia main PC board/noise analysis 


This note summarizes a meeting held this morning re: investigation of potential 
analog/digital interaction on the main Hestia board. 

While the board layout was carefully designed to avoid this problem, we wished to confirm 
that conducted and radiated noise from traces carrying high current switching waveforms 
was minimized, and prevented from entering the RF signal path. 

Attendees: arya, bill, graham, rmm, yves 

We concluded that the analysis should be done in two parts: 

(1) Obtain an understanding of noise levels and mechanism of conduction, as follows: 

(a) Obtain an unpopulated board, with any undesired shorted vias removed. 

(b) Connect a pulse generator to the Euterpe Vcc/GND at the power supply, and measure 
induced voltages on Calliope Vcc/GND as a function of frequency. 

(c) Load decoupling capacitors on the board. Repeat (b) . 

(d) Investigate the effect of adding shields to the board, and/or board installation 
within the (shielding) STB case; repeat (b) . 

(e) If the induced voltages are very small (we hope sol), increase switching currents by 
driving a CMOS power device, drawing current via the DRAM power pads, and repeat 
measurements . 

(f) Load all the components in the RF input circuit, and also measure the induced voltage 
at the F connector and at the differential input to Calliope. 

[The requirement here is <luV in a 6MHz bandwidth] . 

(2) Verification of results, on a larger sample of units: 
Perform test (f) only, and collate statistics on measured noise. 

Action items: All attendees, coordinating with Wayne. 
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From: noe! (Noel Verbiest) 

Sent: Tuesday, January 24, 1995 7:45 PM 

To: 'boxers'; 'dbulfer 1 ; 'tbe@MicroUnity.com' 

Cc: 'pandora' 

Subject: Re: Pandora open actions, can we close?? 


> From tbe@MicroUnity.com Tue Jan 24 11:10:01 1995 

> Date: Tue, 24 Jan 95 11:09:54 PST 

> X- Sender: tbe@gaea.microunity.com 

> Mime-Version: 1.0 

> Content -Type> : > text/plain> ; > charset="us-ascii" > 

> To: boxers, dbulfer 

> From: tbe@MicroUnity.com (Tom Eich) 

> Subject: Pandora open actions, can we close?? 

> Cc : pandora 

> Content -Length: 274 9 
> 

> On 1/12, tbe (Tom Eich) wrote: 
> 

> Actions and status are as follows: 
> 

> >1) Noel to prepare a power spreadsheet with current by voltage per 
module 

> or 

> >lowest separable unit . 
> 

> Status: in progress. 
> 

> Can this be completed, please? The copy I have still has no fan load 

> accounted for, and also has the incorrect Calliope module power (102W) 
that 

> Graham corrected. 


Graham will release a new power estimation on the Calliope modules shortly. Will put the 
new numbers in as soon as I have them. 


> >snip< 
> 

> Action: Philip and Noel to prepare power supply trade matrix. 
> 

> Done, I think. Philip and Noel, are you satisfied? 
> 

> Action: Noel to survey vendors and id candidate supplies. 
> 

> what is the status, please? 
> 

> >snip< 


So far the search for an off-the-shelf unit with own cooling has been 
pretty inconclusive and it is probably time for us to reexamine our 
approach. Of f- the- shelves singles do not have the mix of output voltages/ 
currents, or they don't have power factor correction, or the vendors are 
not responsive because of the low volumes . The ones that respond quote 
leadtimes of 3 to 6 months (semi custom solutions) . 

If we tackle the problem from another angle, and are willing to give up 
the internal cooling, and are willing to accept multiple packages then a 
number of off-the-shelf solutions are instantly available to us. 
Are we willing to consider this ? 
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> >4) Noel and Vijay to id all signal and signal ground I/O lines for 
both the 

> >Euterpe and Mnemo bricks >snip< 
> 

> Status: in progress; signal and signal ground requirements identified. 

> 

> Has an interconnect list or table been prepared? 

> In another message, Jay Tomlinson requested p/ns for the connectors, has 

> this been done? 
> 

> Action: Determine power requirements (ref . 1) above) and candidate 
power 

> connectors and bus bars. 
> 

> What is the status? I am using the Eicon power connector for now, but 

> believe there is an open question on Calliope module power I/O. 
> 

> >5) Noel to identify de- coupling cap requirements and tbe to include in 
area 

> calculations and layouts. 
> 

> Action: in progress. 

> 

> Can you please close this, Noel? 

> >snip< 


The filtering will be heavily influenced by the choice of the power 
supplies. If we need to apply heavy duty filtering, we can fit the 
components inside a rectangular space measuring 1" x 1" x 1.5" for the 
Euterpe and the Caliope Bricks. Somewhat smaller for the Mnemo' s (1" x 
1" x 1" ) . These spaces should be at the power entry points. 


> >8) Herman to trade-off integral Mnemo fan vs. external system 
blower (s) ; tbe 

> >and jt to support with layout concepts. 
> 

> Decision taken to pursue system level blowers for Mnemo modules and PCI 
cards 

> as a first course, due to noise, size and power impact of individual 
module 

> fans . 

> 

> Open action on material/finish for Mnemo heat sink. Can Herman, Vijay 
and 

> tbe meet tomorrow at 2:00 to complete action? 
> 

> >snip< 
> 

> Action: Noel and David to determine location and type of thermal 
protection in 

> Pandora . 
> 

> Status? 


No decisions taken yet. Still being debated. 


> Discussed the PCI card containing the Mnemo and external Hermes port 
(for 

> hestia, etc) . If this card conforms to the PCI mechanical standard, 
then this 

> Mnemo will need a different heat sink than planned for the modules. 
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Herman 

> said this was possible, but needed to be assessed. 
> 

> Action: David raised concern relative to 3 . 3Vdc input if this is 
standard PCI 

> card that could go in any slot. How to resolve? 
> 

> Action: Herman to determine feasibility of low profile heat sink and 
required 

> flow rate. 
> 

> Let's discuss at the 2:00 tomorrow, Herman. 

> >snip< 
> 

> Please respond via E-mail to the newsgroup to provide status and close 

> these out . 

> 

> -Tom 


> Tom Eich 
tbe@microunity . com 

> MicroUnity Systems Engineering, Inc. 

> 255 Caspian Dr. Sunnyvale, CA 94089 

> (408)734-8100, (408)734-8136 fax 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Tuesday, January 24, 1995 9:41 PM 
'Brendan Eich' 

Re: gnu-tools/sim/terp cycles.c 


> Where do you see cc botches? I don't see any when running apps/bench 

> or kernel. reg (the second- to-top version; fambro removed some mpeg2-in 
testing 

> for some reason) . I'll run apps/tv later tonight. If the cc botches 
didn' t 

> happen yesterday, and mpeg2-in hasn't changed, what has changed? 

Like I said, I didn't notice it later, but it happened in last night's regression runs of 
tv.reg (both stable and current) and happens now if you try to run it. The messages are 
definitely from mpeg2-in. Perhaps it's something to do with binding to more than one PID? 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: 
Sent: 

To: 

Subject: 


mws (Mark Semmelmeyer) 
Tuesday, January 24, 1995 10:18 PM 
'billz'; 'dickson'; 'geert'; 'lisar*; 'woody' 
euterpe.V 6.348 


I checked in euterpe.V 6.348 and some uu stuff which is corequisite with an AT change. 
This is to fix the UUvldNoXcRll timing problme. 

The AT half of the change is delayed some. I recommend you not check out the uu stuff (it 
is not BOM'ed) and if you have to modify euterpe.V, modify 6.347 instead and then relabel 
it 

6.34 8 in your CVS/Entries file to skip the 6.34 8 version. 
Hopefully this window of danger will pass soon. 
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From: woody (Jay Tomlinson) 

Sent: Wednesday, January 25, 1 995 1 2:55 AM 

To: 'mws (Mark Semmelmeyer)' 

Cc: 'billz'; 'tor'; 'dickson'; 'geert'; lisar' 

Subject: euterpe.V 6.348 

Mark Semmelmeyer wrote (on Tue Jan 24); 
I checked in euterpe.V 6.348 and some uu stuff which is corequisite 
with an AT change. This is to fix the UUvldNoXcRl 1 timing problme. 
The AT half of the change is delayed some. I recommend you 
not check out the uu stuff (it is not BOM'ed) and if you have 
to modify euterpe.V, modify 6.347 instead and then relabel it 
6.348 in your CVS/Entries file to skip the 6.348 version. 
Hopefully this window of danger will pass soon. 

eutepe.V 6.349 has been checked in along with the at changes that are 
necessary. 5 woody fabbed. dcacheeasy went to bad. I will investigate further. 

Jay 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Gregg Kellogg [gregg@hts.microunity.com] 
Wednesday, January 25, 1995 1:08 PM 
'Lisa Repka' 

'gmo@calliope'; 'fur'; 'brendan*; 'jsw*; 'guarino' 
Re: simulator finally fixed 


On Jan 25, 11:00am, Lisa Repka wrote: 

> Subject: simulator finally fixed 

> The changes I just checked- in should make tv work now. I put a terp 

> and a tgdb in ~lisa/bin/sgi5 for you to use until good ones are built 

> and installed. 
> 

> lisa 

>-- End of excerpt from Lisa Repka 

Thanks very much for getting this fixed! I'm checking it out right now. 


Gregg Kellogg 

MicroUnity Systems Engineering, inc. 

255 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, January 25, 1995 7:12 PM 

To: 'geeiK^rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/at BOM 43.0 initiated by brianl completed @ Wed Jan 25 
17:07:31 PST 1995 with exit status 0.. chip 
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Sent; 

To: 

Cc: 


Subject: 


From: 


bill (William Herndon) 

Wednesday, January 25, 1995 8:02 PM 

'solo@hera.microunity.com'; 'brianl' 

'geert' 

Re: clock load 


> From brianl Wed Jan 25 17:11:15 1995 

> From: brianl (Brian Lee) 

> Subject: Re: clock load 

> To: solo@hera.microunity.com (John Campbell) 

> Date: Wed, 25 Jan 95 17:11:10 PST 

> Cc: bill (William Herndon), geert (Geert Rosseel) 

> X-Mailer: ELM [version 2.3 PL11] 

> Content -Length: 811 
> 

> John Campbell writes: 
> 

> what's the recommended clock loading these days. i am doing a custom 

> block for test and don't have a clue. i am driving mostly scsynchll 

> flipflops which have a heavy load like 1.8mA of isrc on the clocks. 
> 

> is there a file i should be looking at. 

> 

> Hmmmm. If I understand the question correctly, then I'm not sure that 

> I know the answer. For normal signals, we tell topt to limit the dc 

> load current to 10% of the driving output current. 25% if it's an 

> emitter follower output. I don't know if clocks have different 

> constraints. Is this what you were looking for? Will someone else 

> help out here? 
> 

> BTW, the latest capacitance and current numbers that were simulated 

> for the sofa custom cells are in 
> 

> /u/chip/proteus/custom/ { caps, dc load }/<cell>. {cap, cur} 


> Brian L. 

> 

clock is simulated with 600ff capacitive load and 3 0 lOOua switches gives 15 0mv pp swing 
at 750ps period for the euterpe style clock, cgde.., 30 lOOua switches is 3ma of switch 
current fed by the clock driver, 3000ma/60 is 50ua base current at a beta of 60.. 
the big issue 

in the case of the clock is the diffusion capacitance that it has to drive. 
At 920ps period we get about I70mv pp swing with 3 5 lOOua switch loads. 

The clock driver is a 250mv 150ua switch, with 50ua steady state and 750ua switched 
emitter follower current. A reasonable extra dc load would be 15 0ua * 1/10 
* (beta = 60) 

= 900 ua, so i guess i am saying that the switched load emitter current should be less 
than 3.5ma, (3500ua/60 ) =58ua actual effective base load. The clock driver is a 2p level 
and has to go directly into a switch. . 
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From: ong (Warren R. Ong) 

Sent: Thursday, January 26, 1995 10:51 AM 

To: 'Drew Wingard' 

Cc: 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)' 

Subject: Re: vy differential drivers? 


>From Drew Wingard . . . 
@ 

@ Fred wrote (sorry about the delay. . . ) : 

@ > My question is that Drew wanted me to disallow differential inputs to be @ > driven 
from complementary outputs coming from different instances. If we @ > want to allow this 
type of hook-up, I think that I'll need to change the @ > code to find all pairs of 
drivers for each instance. 
@ > 

@ > Should for example, the following be legal? 
@ > 

@ > 13 

® > II a_a0pfwy > + > d_ad0ph 

@ > | 

® > a_an0pfwy > + > d_and0ph 

® > II 

@ > 12 b_a0phwy > | j 

@ > | 

@ > b_an0phwy > j 

@ > 
@ 

@ I think that the above case should be legal, although I suspect that it @ doesn't occur. 

I would think otherwise about letting this be legal. What if a_aOpfwy and a_an0pfwy do 
not slew at the same time, and it results in both inputs being low for several gate 
delays? This could saturate the receiving circuit, and for bicmos designs, might trigger 
latch up . 


@ 

@ I'm quite sure that Warren's case should be legal, but I think that @ it uses a 
■custom' swing rather than a 'h' or 'f ' . Since our standard @ cells don't have 'w' nor 
■y* qualifiers, this can't happen there. 

In the case of the exlax memory cells, the memory cells themselves are the drivers and 
they *are* differential. The other circuit connected to the rbl_abn*d0p85vy signal is the 
input of dout circuit. I do not expect this net to ever be driven by complementary and 
non-differential signals. 

So, if the above example never occurs, and it is not desirable, then we should be able to 
disallow it without affecting the results from Euterpe. 

@ 

@ I think that the presence of 'w' or 'y' on the drivers should probably @ enable an 
enhanced checking algorithm that pairs up the drivers . 
@ Is this expensive to implement? 
@ 

@ Sorry again for the delay, 

@ Drew 

@ 


Warren . 
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From: vo (Tom Vo) 

Sent: Thursday, January 26, 1 995 1 1 :56 AM 

To: Tim B. Robinson' 

Subject: Re: euterpe/verilog/bsrc/ce cerberus.cpif 

Tim B. Robinson wrote .... 

> 
> 

>Tom Vo wrote (on Wed Jan 25): 

> 

> Update of /p/ cvsroot/euterpe/veri I og/bsrc/ce 

> In directory ghidra:/s5/vo/euterpe/verilog/bsrc/ce 

> 

> Modified Files: 

> cerberus.cpif 

> Log Message: 

> moved octlet 6 . This version is electrically no good , but has the right 

> number of wires through the choke points . More work is needed . 

> 

>Is it still logically OK? 

> 

>Tim 

> 

Probably not . I need to redo the clock buffering going to this 
octlet and octlet 10 . There're also performance related edits 
for outputs to toplevel to be performed . 

tvo 
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From: jeffm (Jeff Marr) 

Sent: Thursday, January 26, 1995 5:15 PM 

To: lisar 1 ; 'veena'; 'doi'; 'karzes' 

Cc: 'tbr'; 'dickson' 

Subject: illegal group shift/rot/exp/comp immediates 

This is a followup to the question of whether the the following are 
exception or don't care cases: 

The immediate shift amount is greater than, 
or equal to, the size for group shift, rotate, 
expand, and compress immediates. 

Dickson did not implement these as trap cases - they are 
don't cares, 

Terp is implemented the same way. 

The assembler does not complain about the cases, nor does it 
truncate them. 

The TSA of 14 April, pg 109, indicates that these should be 
reserved instruction exceptions. 

Whatlitbe? 

jeffm 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tom Karzes [karzes@scylla] 

Thursday, January 26, 1995 5:52 PM 

, craig@scylla'; 'tbr@scylla'; 'jeffm@scylla' 

, lisar@scylla'; Veena@scylla'; 'doi@scylla'; 'dickson@scylla' 

[jeffm: illegal group shift/rot/exp/comp immediates] 


Jeff Marr writes: 

> This is a followup to the question of whether the the following are 

> exception or don't care cases: 


> The immediate shift amount is greater than, 

> or equal to, the size for group shift, rotate, 

> expand, and compress immediates. 


> Dickson did not implement these as trap cases - they are don ' t cares . 

> Terp is implemented the same way. 

> The assembler does not complain about the cases, nor does it truncate 

> them. 

> The TSA of 14 April, pg 109, indicates that these should be reserved 

> instruction exceptions. 

> 

> Whatlitbe? 

One correction here: For expand and compress, the exception should only be generated if 
the shift amount is greater than, or equal to, the larger of the two group sizes involved. 
This is the most natural group size, and is what is used in the XLU interface, but for 
historical reasons the instruction encoding uses the smaller group size. So for these 
cases, the exception would be generated if the shift amount is >= twice the group size. 
Note that this was a change: At an earlier time, the limit was the smaller group size, 
which explains the historical encoding. 

As far as not supporting out- of -range exceptions for immediate shift amounts, I believe 
this is a departure from the Terpsichore architecture. As far as I know, out -of -range 
immediate shift amounts were always supposed to generate exceptions. The XLU 
microarchitecture notes that I wrote were very unclear about this (they simply noted that 
the XLU would ignore any bits beyond the valid range, and in fact the XLU doesn't even 
know when it's being given an immediate vs. a non-immediate shift amount) . However, I had 
always assumed that the trap conditions would be implemented according to the architecture 
manual . 

At this point, I think we need to answer the following questions: 

1. How important is it to fix this, i.e., add the exceptions? 

2 . How much work would be involved in fixing it? 

3. If we don't fix it, should the assembler mask off the bits 
which are ignored, possibly with a worning, to make it 
easier to make these reserved in the future? 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wingard (Drew Wingard) 

Friday, January 27, 1995 2:42 AM 

'tbr' 

'geert'; 'hopper'; 'torn' 
Re: HTML stuff 


Tim wrote: 

> Please see ken tomorrow to get what you need done. Eric is sending 

> him some pointers. 


Great ! 


> Meantime, please explain the problem again. Lisar has a bunch of 

> linked pages set up in the veryfy area. With no special macros or 

> anything, we appear to able to navigate OK up and down across symlinks 

> just as i think one would want. {ie not the same as what the 

> corresponding set of cd's would have done). Furthermore, we seem to 

> be able to reach any file in the filesystem. 
> 

> I thought from what you had said that a) you could only see things in 

> a few restricted places, and b) once you had gone down a symlink you 

> got lost comming back up. 

I'll be glad to take a shot at explaining it. 

Mosaic (as a WWW client) presents two basic ways to access external files. 

Well, actually it gives a lot more, but I think only two are really useful to us. 

Most HTML documents are served from external machines, and the preferred (both in terms of 
performance and features) method of access to files on external machines is via the 
HyperText Transfer Protocol (HTTP) . Here the Mosaic client communicates over a 'well- 
known' port (typically port 80) to the 'httpd' daemon on the remote machine. The 'httpd' 
process typically runs as the user 'nobody to limit its permissions, and furthermore has 
tight restrictions on where in its filesystems it will look for files to serve to the 
outside world. 

This is the origin of the restriction "a)" that you note above. 

The primary alternate method we could consider using (and the one we were using until bobm 
found WebStar) , is called the "file" access method. 

Here, Mosaic will look on the locally-accessible file systems (with the permissions 

associated with the user invoking Mosaic) if the 'remote' 

machine associated with the link is specified as the local machine (i.e. 

' f ile : //localhost ' at the beginning of the Universal Resource Locator 

(URL) that points to the file) . 

This sounds really convenient and good, and it is as long as: 

1) you can decide at the time you create/install the document where all the 

files that you might want to link to will be located. 

2) you never need to pass any link- specif ic arguments to any commands that 

you might want to call 

The problem, as I saw it, with the first restriction is that if our documentation is to 
truly be a 'first-class' design database component that it should follow the basic rules 
that our other components do. 

In particular, we have gone to quite a bit of effort to build a system that allows user to 
check out only a subset of the entire design space and yet operate as if the entire design 
were at hand. We've done this, at least in part, through liberal use of symbolic links. 

But we have problems when folks try to point to another file using paths like 

. . /another_dir/f ile because you end up in a different place than expected if .. doesn't 

point to the same place from which the symbolic link came, 

A major mechanism that we use to get past this is to express many paths as relative to 
$CHIPROOT. 


Exhibit CIO 


Page 300 of 356 


When I tried to set up the documentation using $CHIPROOT and "file:" 
access 

it became apparent that I had a problem. Since Mosaic reads "file:" HTML files without 
passing them through any filters there was no simple way for me to dynamically change 
$ CHIPROOT- relative links to match any given user's setup. My best alternative was to 
'compile' CHIPROOT into each HTML file in a Makefile -directed process. Thus, files in a 
checked out tree would have the correct value for that tree, but files in symbolically- 
linked directories would have CHIPROOT set to /u/chip/something (typically) . 
This concerned me not only because it could be confusing to a designer, but also because I 
wanted a reliable way to get back to a checked-out design's "home page" from every 
document, and I clearly couldn't get there from a pointer to the 'wrong' CHIPROOT. 

The alternative is to try to use a true relative path from everywhere. 

However, I found that the Mosaic I was running did something unexpected: 

on "http:" accesses the Mosaic client itself interprets dir/ . . /other__dir - style paths, 

collapsing the path before sending it to the server. 

"File:" accesses, on the other hand, didn't always get collapsed before going to the file 
system. 

Thus, paths such as "verilog/ .. /compass/cell . html " got passed to the file system and thus 
ran into the symbolic link problem that caused us to want CHIPROOT in the first place. 
Even if we modified Mosaic not to do this, do we really want to use relative paths all 
over the place? Sigh. . . 

OK, so how do we fix this problem? One idea was to modify Mosaic to pre-process all HTML 
files it receives and do a 'sed' -style string substitution on all CHIPROOT strings that it 
saw. Of course we'd also need to teach Mosaic how to learn the desired value of CHIPROOT, 
and probably also how to modify it during a session. Seemed like a hack, and a painful 
one at that. 

Then bobm found Webstar. WebStar is a program started by the httpd server. 
One of the benefits of being started by httpd, rather than by Mosaic itself, is that the 
forked program can take arguments that are specified in the HTML link itself. An invoked 
WebStar parses all of the arguments passed to it and looks for ones which specify an HTML 
file to return. However, WebStar processes the file before returning the file to Mosaic - 
it looks for embedded Tel commands to execute. The Tel commands typically use the 
arguments that were passed to WebStar to modify the contents of the returned document . 

In our case, an obvious use of WebStar is to handle the CHIPROOT problem. 

If one of the arguments to WebStar is always the currently- defined CHIPROOT, then WebStar 
can easily substitute that value into the documents that it returns. Thus WebStar gives 
our documents the ability to store state. 

Which brings us to the other reason why I don't think "file:" access is a good choice. 
Mosaic has a mechanism to start up commands to 'view' 

non-html documents. For instance, bobm uses this mechanism to fire up Frame to look at 
files ending in .mif . A significant problem for some of the applications that we might 
want to start {like Concept) is that the returned file gets a computer-generated name 
(i.e. rather than simply passing xlu.mif to Frame, Mosaic copies xlu.mif to 
/tmp/aaaa2134 .mif and passes the tmp file to Frame) . So, for a program like Concept that 
wants to start up in a specific directory one might want to instead have Mosaic run a 
shell script that did the 'right' thing. Unfortunately, since Mosaic won't pass that 
script any HTML- specif ied arguments (not even the name of the original script) the 
resulting script needs to 'know' 

everything about what it needs to do. Such as the full path of the directory where the 
actual design file(s) live. 

I thought doubling the number of design files (i.e. one script per design source file) 
sounded like a bad idea. 

An alternative would be to use "file:" accesses for HTML files and "http:" 
accesses to start up helper scripts to access other design files. 
Unfortunately, specifying the path to the other files is problematic. 

You see, there's no way to feed a "http:" reference a path that is relative to the current 
"file:" access. So by using "http:" we gain the ability to pass arguments, but we lose 
the ability to specify relative paths. 
Sigh. . . 
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But WebStar can help us with this. Since the HTML files are accessed through "http:", we 
can encode state in the returned files. This state can then be passed to the helper 
scripts. And then the helper scripts can return the proper data to Mosaic so it can start 
up the proper local application to load the proper design file. 

And we intend the user interface to be very simple macro calls. For instance, "to see the 
Makefile definitions click CHIPREF {here, Makefile .defs) " or "to look at the schematic click 
CONCEPT {here , camcell) and to examine the layout click COMPASS (here , 
$ CH I PROOT/ compass , camcell) " . 

Note that the latter two macros have not been implemented yet, but should be relatively 
soon. 

I hope some of this makes sense. It certainly took a while to type! 
Drew 

P.S. - there may be security risks associated with given WebStar access to the filesystem. 
I don't think WebStar can do anything worse than return 

(potentially) every file readable by the user 'nobody'. In particular, I don't think a 
remote user can cause any other programs to get executed on the server side. Anything 
which might get executed on the client side is of course executed as the user running 
Mosaic . 
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Subject: 


From: 


Sent: 
To: 

Cc: 


tbr (Tim B. Robinson) 
Friday, January 27, 1995 10:49 AM 
'wingard (Drew Wingard)' 
'geert'; 'lisar'; 'hopper'; 'torn' 
Re: HTML stuff 


Drew Wingard wrote (on Fri Jan 27) : 
Tim wrote: 

> Please see ken tomorrow to get what you need done. Eric is sending 

> him some pointers. 


> Meantime, please explain the problem again. Lisar has a bunch of 

> linked pages set up in the veryfy area. With no special macros or 

> anything, we appear to able to navigate OK up and down across symlinks 

> just as i think one would want. (ie not the same as what the 

> corresponding set of cd's would have done). Furthermore, we seem to 

> be able to reach any file in the filesystem. 
> 

> I thought from what you had said that a) you could only see things in 

> a few restricted places, and b) once you had gone down a symlink you 

> got lost comming back up. 

I'll be glad to take a shot at explaining it . 

Mosaic (as a WWW client) presents two basic ways to access external files. 
Well, actually it gives a lot more, but I think only two are really useful to 
us . 

Most HTML documents are served from external machines, and the preferred 
(both in terms of performance and features) method of access to files on 
external machines is via the HyperText Transfer Protocol (HTTP) . Here the 
Mosaic client communicates over a 'well -known 1 port (typically port 80) 
to the 'httpd' daemon on the remote machine. The 'httpd' process typically 
runs as the user 'nobody' to limit its permissions, and furthermore 
has tight restrictions on where in its filesystems it will look for files 
to serve to the outside world. 

This is the origin of the restriction "a)" that you note above. 

The primary alternate method we could consider using (and the one we were 
using until bobm found Webstar) , is called the "file" access method. 
Here, Mosaic will look on the locally-accessible file systems (with the 
permissions associated with the user invoking Mosaic) if the 'remote' 
machine associated with the link is specified as the local machine 
(i.e. 1 f ile : //localhost ' at the beginning of the Universal Resource Locator 
(URL) that points to the file) . 

This sounds really convenient and good, and it is as long as: 

1) you can decide at the time you create/ install the document where all the 

files that you might want to link to will be located. 

2) you never need to pass any link- specif ic arguments to any commands that 

you might want to call 

The problem, as I saw it, with the first restriction is that if our 
documentation is to truly be a 'first-class' design database component that 
it should follow the basic rules that our other components do. 
In particular, we have gone to quite a bit of effort to build a system that 
allows user to check out only a subset of the entire design space and yet 
operate as if the entire design were at hand. We've done this, at least 
in part, through liberal use of symbolic links. 


Great ! 
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But we have problems when folks try to point to another file using paths 

like . . /another_dir/f ile because you end up in a different place than expected 

if doesn't point to the same place from which the symbolic link came. 

A major mechanism that we use to get past this is to express many paths 

as relative to $CHIPROOT. 

This is the point I was having trouble with, because when I tried this, ../blah did what 
I think I wanted, not what I expected. ie it did not do the same as cd would have done. 
So I could go down my local tree and through a link to something, then follow a pointer 
with . . in it and get back to where I was even thought there was a symlink. 


When I tried to set up the documentation using $CHIPROOT and "file:" 
access 

it became apparent that I had a problem. Since Mosaic reads "file:" 
HTML 

files without passing them through any filters there was no simple way for 
me to dynamically change $CHlPROOT- relative links to match any given user's 
setup. My best alternative was to 'compile' CHIPROOT into each HTML file 
in a Makefile-directed process. Thus, files in a checked out tree would 
have the correct value for that tree, but files in symbolically- linked 
directories would have CHIPROOT set to /u/chip/something (typically) . 
This concerned me not only because it could be confusing to a designer, 
but also because I wanted a reliable way to get back to a checked-out 
design's "home page" from every document, and I clearly couldn't get 
there from a pointer to the 'wrong' CHIPROOT. 

The alternative is to try to use a true relative path from everywhere. 
However, I found that the Mosaic I was running did something 
unexpected : 

on "http:" accesses the Mosaic client itself interprets dir/ . . /other_dir - 
style paths, collapsing the path before sending it to the server. 
"File:" accesses, on the other hand, didn't always get collapsed before 
going to the file system. 

Thus, paths such as "verilog/ .. /compass/cell .html" got passed to the file 
system and thus ran into the symbolic link problem that caused us to want 
CHIPROOT in the first place. Even if we modified Mosaic not to do this, 
do we really want to use relative paths all over the place? Sigh. . . 

Probably not . 

OK, so how do we fix this problem? One idea was to modify Mosaic to 

pre-process all HTML files it receives and do a 1 sed' -style string substitution 

on all CHIPROOT strings that it saw. Of course we'd also need to teach 

Mosaic how to learn the desired value of CHIPROOT, and probably also 

how to modify it during a session. Seemed like a hack, and a painful one 

at that. 

Then bobm found WebStar. Webstar is a program started by the httpd server. 
One of the benefits of being started by httpd, rather than by Mosaic itself, 
is that the forked program can take arguments that are specified in the 
HTML link itself. An invoked Webstar parses all of the arguments passed to 
it and looks for ones which specify an HTML file to return. However, 
WebStar processes the file before returning the file to Mosaic - it looks 
for embedded Tel commands to execute. The Tel commands typically use the 
arguments that were passed to WebStar to modify the contents of the 
returned document . 

In our case, an obvious use of WebStar is to handle the CHIPROOT problem. 
If one of the arguments to WebStar is always the currently- defined CHIPROOT, 
then WebStar can easily substitute that value into the documents that it 
returns. Thus WebStar gives our documents the ability to store state. 

Which brings us to the other reason why I don't think "file:" access is 
a good choice. Mosaic has a mechanism to start up commands to 'view' 
non-html documents. For instance, bobm uses this mechanism to fire up 
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Frame to look at files ending in .mif . A significant problem for some of 
the applications that we might want to start (like Concept) is that 
the returned file gets a computer-generated name (i.e. rather than simply 
passing xlu.mif to Frame, Mosaic copies xlu.mif to /tmp/aaaa2134 .mif and 
passes the tmp file to Frame) . So, for a program like Concept that 
wants to start up in a specific directory one might want to instead have 
Mosaic run a shell script that did the 'right' thing. Unfortunately, 
since Mosaic won't pass that script any HTML- specified arguments (not even 
the name of the original script) the resulting script needs to 'know' 
everything about what it needs to do. Such as the full path of the 
directory where the actual design file(s) live. 

I thought doubling the number of design files (i.e. one script per design 
source file) sounded like a bad idea. 

An alternative would be to use "file:" accesses for HTML files and "http:" 
accesses to start up helper scripts to access other design files. 
Unfortunately, specifying the path to the other files is problematic. 
You see, there's no way to feed a "http:" reference a path that is relative 
to the current "file:" access. So by using "http:" we gain the ability to 
pass arguments, but we lose the ability to specify relative paths. 
Sigh. . . 

But Webstar can help us with this. Since the HTML files are accessed through 
"http:", we can encode state in the returned files. This state can then 
be passed to the helper scripts. And then the helper scripts can return 
the proper data to Mosaic so it can start up the proper local application 
to load the proper design file. 

And we intend the user interface to be very simple macro calls. For instance, 
"to see the Makefile definitions click CHIPREF (here, Makefile . defs) " or 
"to look at the schematic click CONCEPT ( here , camcel 1 ) and to examine the 
layout click COMPASS (here, $ CHI PROOT/ compass, camcel 1) " . 

Note that the latter two macros have not been implemented yet, but should be 
relatively soon. 

I hope some of this makes sense. It certainly took a while to type I 

Yes, it's a big help. 

P.S. - there may be security risks associated with given Webstar access to 
the filesystem. I don't think Webstar can do anything worse than return 
(potentially) every file readable by the user 'nobody' . In particular, 
I don't think a remote user can cause any other programs to get executed on 
the server side. Anything which might get executed on the client side is 
of course executed as the user running Mosaic . 


Exhibit CIO 


Page 305 of 356 


From: wampler (Kurt Wampler) 

Sent: Friday, January 27, 1 995 11 : 1 9 AM 

To: 'tbr' 

Cc: 'brianl'; 'ericm'; 'torn'; 'wampler' 

Subject: Re: gardswart makefile problem in snapshot? 

I suppose since the original mail on this subject was addressed to me that 
a response is due. :-) I think most questions have already been answered 
but I will try to collate & summarize in a single e-mail. Here goes... 

-Kurt 


tbr writes: 


>Howcome this has never shown up in any other use of v2e. We use it a 
>lot, with the standard definitions from Makefile. defs. Also, are we 
>sure we are not throwing the baby out with the bath water here? The 
>whole reason for rexec existing in the first place was to try and 
>reduce the actually use of rsh in the typical case because of the name 
Resolution problem. 

torn responds: 

>Actually, it did show up once before, some months ago — torn vo had the 
>core-dumping problem that time, if I recall correctly. The core- dump 
>only occurs when a global "export' is used in the Makefile, the remote 
>machine is the same as the local machine, and the user's login shell 
>has a low tolerance for large environments (tcsh has the problem; sh 
>doesn't; not sure about others). 

wampler responds: 


I volunteer to look at the source code for tcsh to see if I can make it 
insensitive to large environment. It shouldn't core dump! 

The gardswart Makefile did not exhibit this problem before because it was 
relying on the default behavior of the /u/chip/tools/bin/v2e wrapper; 
its default was always to rexec to staypuft to run v2e. The 
proteus/Makefile. rules didn't exhibit this problem because it wasn't doing 
a global export of Make variables and thus did not crash the local shell 
(for those users using tcsh, and possibly csh). 

tbr continues: 


><Entering pontification mode> 

> 

>I still feel it would be prefererable to export only those things 
>you really need with 

> 

>export VAR1 
>export VAR2 

> 

>etc. In the general case, the global export makes it 
impossible to use the construct 

> 
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>FOO = $(shell <some command that takes a long time>) 

> 

>because it causes an infinite recursion. (Make tries to put it in the 
>enviornment before invoking the shell, but to calculate the value it 
>needs to invoke the shell. One might call that a bug in gmake.) 

> 

>Using := is not good in the case that the shell command takes a long time 
>and is only needed for a specific rule. I ran into this when the 
>'export' suddenly popped up in the euterpe/Makefile. share. In that 
>case the shell command took 15 ninutes and was being invoked with 
>every make run even though I only needed the result for one particular 
>target. 
> 

><Leaving pontification mode> 
wampler responds: 


My goals in using gmake's global export were: 

1 ) Satisfy the requirement that the shell scripts used in the gardswart 
build process be sensitive to the tool definitions in Makefile.defs. 

I experimented with writing a shell script to parse Makefile.defs, but 
abandoned this because it cannot accurately reproduce the complete 
list of Make variables, since it doesn't know which ones have been 
overridden by a local Makefile, command-line overrides, etc. 

2) Decouple maintenance of gardswart shell scripts from the gardswart 
Makefiles. Using the explicit export model requires a coordinated 
change to the Makefile any time the shell script needs to pick up 

a new variable. Also, since these shell scripts tend to invoke a 
number of tools, the number of variables needing to be explicitly 
passed to the script is large (order 20 variables), and I wanted to 
avoid the ugliness of that long list of variables in the Makefile 
every time it calls a script. And, of course, each script requires 
a different subset of the variables. 

ericm comments: 


>i could have rexec stop the environment before exec() but kurt 
>and tom's feeling was that it'd be better to have consistent behaviour 
>by always doing the rsh instead. 

wampler agrees: 


I think consistent behavior, regardless of whether the host specified 
happens to be local or not, is of paramount importance. 

tbr wonders: 


>(As an asside, whats the performace hit of passing a huge environment 
>each time there is a forkO? In BSD at least it used to be horrible 
>with it getting probed and copied one character at a time. I would 
>hope it's been tuned some since then.) 

wampler responds: 

My experience in using this export has been that the performance hit is . 
not noticeable. Invocations of individual tools zoom by just as fast as 
they used to. I could devise an experiment to measure this overhead if 
we need to quantify it. 
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torn clarifies: 


>I recall the main purpose of rexec being to get back the exit status of 
>the remote process. The old rexec (ericm has changed this), by avoiding 
>the rsh when the remote machine was the local machine, had the effect of 
>potentially inconsistent behavior. The environment was passed to the 
>program if remote-machine == local-machine, but wasn't otherwise. 

wampler responds: 


I recall this also as the primary design goal of rexec - to provide a 
robust, consistent replacement for "rsh", which properly returns the exit 
status of the remote command. 

torn proposes: 


>It might be nice to have a program like rexec that made the remoting be 
>really transparent (passing environment, current directory, etc)... 

wampler seconds: 

I agree this would be a useful feature, either as a switch on the current 
rexec or as a separate parallel script. 
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From: Frank Paturzo [fgp@gaea] 

Sent: Saturday, January 28, 1995 12:59 PM 

To: Tim B. Robinson' 

Cc: 'sysadmin@gaea'; 'geert@gaea' 

Subject: Re: forwarded message from Geert Rosseel 

At 11:37 AM 1/28/95, Tim B. Robinson wrote: 

>Can someone reboot godzilla, gamorra, ghidra and mothra please? 

>They all have the NFS stale file handle problem for auspex :/s41 which 

>is unfortunately one of the main Euterpe partitioins. 

>They all seem to be idle at present (not surprising since they can't 

>get to s41. 

> 

>Tim 

> 

> 

> Start of forwarded message 

>Status: RO 

>X-VM-v5-Data : ([nil nil nil nil t nil nil nil nil] 

> ["14 6" "Sat" "2 8" "January" "1995" "11:25:06" "-0800" "Geert 
>Rosseel" "geert 11 "<199501281925 . LAA17 619@ambiorix. microunity . com>" "5" 
>"Re: auspex" " A From:" nil nil "1"]) 

>Return-Path: <geert> 

>Received: from ambiorix.microunity.com by gaea.microunity.com 
(4 . l/musel.3) 

> id AA23095; Sat, 28 Jan 95 11:25:07 PST 

> Received: from localhost by ambiorix.microunity.com { 8 . 6 . 4/muse-sw. 3 ) 

> id LAA17619; Sat, 28 Jan 1995 11:25:06 -0800 
>Message-Id: <199501281925 . LAA17 6 19@ambiorix. microunity. com> 
>From: geert (Geert Rosseel) 

>To : tbr 

> Subject: Re: auspex 

>Date: Sat, 28 Jan 1995 11:25:06 -0800 

> godzilla, gamorra, ghidra and mothra have problems getting to s41 

> 

> The other big machines seem to be O.K. 
> 

> Geert 

>__ E na ; 0 f forwarded message 


Done . 


Frank Paturzo fgp@microunity.com 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 28, 1995 2:18 PM 

'Frank Paturzo' 

•geert'; ^admin' 

Re: forwarded message from Geert Rosseel 


Frank Paturzo wrote (on Sat Jan 28) : 

At 11:37 AM 1/28/95/ Tim B. Robinson wrote: 

>Can someone reboot godzilla, gamorra, ghidra and mothra please? 
>They all have the NFS stale file handle problem for auspex;/s41 
>which is unfortunately one of the main Euterpe partitioins. 
>They all seem to be idle at present (not surprising since 
>they can't get to s41. 


> 


Done . 


Thanks . 


Tim 
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From: chip (Buffalo Chip) 

Sent: Saturday, January 28, 1995 2:29 PM 

To: 'wampler* 

Cc: tbf 

Subject: Problem with Euterpe Top-level build 


Hi, 

PCOMP died while trying to build the clockbias for the euterpe baseplate. 
This is urgent. It is stopping the build of both the build of the latest 
top-level and of the small euterpe for DRC/LVS. 

Geert 
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From: lisar (Lisa Robinson) 

Sent: Saturday, January 28, 1995 2:31 PM 

To: 'woody' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr" 
Subject: dcacheharder 


Jay there is a dump of dcacheharder_V in /u/tbr/euterpe/verilog/bsrc. 

It goes to X. dcacheharder_0 seemed to hang (ie behave differently) so I have 

that running in verilog too. 

Lisa R. 
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From: Geert Rosseel [geert@rhea] 

Sent: Saturday, January 28, 1995 2:31 PM 

To: 'geert@rhea' 
Subject: pager log, sender copy 

page from geert to wampler: 

Read mail on top-level Euterpe : clockbias problem . Thanks. . geert 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 28, 1995 2:53 PM 

'geert' 

'wampler' 

Problem with Euterpe Top-level build 


Buffalo Chip wrote (on Sat Jan 28) : 


Hi, 


PCOMP died while trying to build the clockbias for the euterpe baseplate. 
This is urgent. It is stopping the build of both the build of the latest 
top-level and of the small euterpe for DRC/LVS. 

I wonder if this could be in any way related to the dot in the path problem recently 
changed int he clockbias stuff. Do you have the logfile with the failure? 


Tim 
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From: vanthof (vant) 

Sent: Saturday, January 28, 1995 3:44 PM 

To: 'geert (Geert Rosseel)'; 'stick (Bruce Bateman)'; 'bpw (B. P. Wong)' 

Cc: 'vanthof (Dave Van't Hof)'; 'solo (John Campbell)'; 'torn (Thomas Laidig)'; 'Eldred Felias'; 'Mark 
Hofmann'; Tim B. Robinson' 

Subject: cache drc errors 


The cache has about 4.7MB of drc errors; 

min active dimension in the long direction = 18 

min emitter feature space = 18 

min emitter implant sapce = 10 

min collector plug spacing = 1 8 

min metal 1 - metal4 min concave edge length = 20 

The majority of the errors fall into the first 3 categories. I've looked 
at a few, but the fixes are not immediately obvious and require a better 
knowledge of the interactions of these layout cells. I can keep looking 
at them, but I don't think I'll do any edits. 

The error file is: /u/vanthof/compass/mobi/euterpe/cache.err 

What sort of impact would waiting until monday to have a real mdunit look 
at these errors have on the generation of the baseplate? 

My personal preference would be to have a chip generated so I can start 
some sort of drc/lvs runs. It has been many many months since this has 
been done. 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 28, 1995 3:52 PM 

'geert (Geert Rosseel)' 

'warn pier' 

Re: Problem with Euterpe Top-level build 


Geert Rosseel wrote (on Sat Jan 28) : 
Hi Tim, 

The output of the make is in 
/n/auspex/s41/euterpe- snapshot /euterpe/euterpe . out 

I am not familiar with the change that you mention. I paged Kurt to look 
at this but he has not responded yet. 

It's in the area I thought, but I don't see what's wrong. Here's the rule that failed: 

# 

# Make the CDL placement rules 
# 

cbsofa.cdl: cbsof a_exclude . ly cbsof a_mask. ly cbmacros.pdl \ 
$ (CPROTO) /get_jprofiles cbsof acdl 

$ (CPROTO) /get_pro files cbmacros.pdl > profiles.txt 
./cbsof acdl profiles.txt cbsof a_exclude . ly > cbsofa.cdl 

The problem is that the binary that's there is not executable. 

I think that must mean it failed to link correctly. I'll try removing it and see if it 
will rebuild. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, January 28, 1995 3:55 PM 

'geert (Geert Rosseel)' 

'wampler' 

Re: Problem with Euterpe Top-level build 


Geert Rosseel wrote (on Sat Jan 28): 
Hi Tim, 

The output of the make is in 
/n/auspex/s41/euterpe- snapshot /euterpe/euterpe . out 

I am not familiar with the change that you mention. I paged Kurt to look 
at this but he has not responded yet. 

Well, I have no idea why it was not executable. I removed it and it remade OK: 

gmakechip@mothra /N/auspex/root/s4l/euterpe- snapshot /euterpe/clockbias 12 % cbsofacdl 
/n/auspex/s41/euterpe- snapshot /euterpe/proteus/clockbias/gsub 
cbsof a_bounds . gsub \ 
< 

/n/auspex/ s41/euterpe- snapshot /euterpe/proteus/clockbias/cbsof acdl . c . tempi 

ate > cbsof acdl. c 

gcc -g cbsof acdl. c -o cbsofacdl 

chip@mothra /N/auspex/root/s41/euterpe- snapshot /euterpe/clockbias 13 % Is -Is 1$ Is -Is 
cbsofacdl 

160 -rwxr-xr-x 1 chip 147605 Jan 28 13:53 cbsofacdl 


So, I think if you re-run your make from the top it should get past it. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, January 28, 1 995 3:57 PM 

To: 'geert (Geert Rosseel)' 

Cc: 'wampler.' 

Subject: Top-level Euterpe 


Geert Rosseel wrote (on Sat Jan 28) : 


Hi, I think I may have found the problem. The make died yesterday because of a 
permission problem but it wrote an empty file that did not get rebuild. 

It wasn't empty: 

320 -rw-rw-rw- 1 chip cad 147605 Jan 27 10:47 cbsofacdl 

but then it wasn't executable either. The new version is the same 
size : 

Is -Is cbsofacdl 
160 -rwxr-xr-x 1 chip 147605 Jan 2 8 13:53 cbsofacdl 

Tim 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Saturday, January 28, 1995 7:03 PM 

'geeif; 'tbr' 

Re: Top-level Euterpe 


> I deleted the clockbias directory, got a BOM and rebuild. That got me 
>up to placement but the clock generation fails here. Kurt, can you look 
>at this, please . . . 

Sorry to be so long in responding; I was out most of the afternoon. 
I think the reason the gplace/clockbias was failing is because thoas 1 s 
X-server died last night during the auspex reboot. (By default it 
directs the display at thoas.) I've restarted thoas ' s X-server, and 
it should work now. It is also possible to override the DISPLAY 
pointer on the gmake command line as well, if this problem recurds 
in the future. 


- Kurt 
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From: lisar (Lisa Robinson) 

Sent: Saturday, January 28, 1995 10:36 PM 

To: 'billz'; 'dickson'; 'mws'; 'woody' 

Cc: 'jeffm'; 'tbr' 

Subject: Dump that are availble 

The following dumps are available - 

/u/tbr/euterpe/ verilog/bsrc/dcacheharder_V .dump 
/u/tbr/euterpe/verilog/bsrc/dcacheharder_0.dump 
/n/nosfaeratu/s2/euterpe/ver i log/bsrc/dcache_fiin c_ 1 . dump 

Lisa R. 
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From: woody (Jay Tomlinson) 

Sent: Sunday, January 29, 1995 1:12 AM 

To: 'lisar (Lisa Robinson)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'rows'; 'tbr' 

Subject: Dump that are availble 


Lisa Robinson wrote (on Sat Jan 28): 

The following dumps are available - 

/u/tbr/euterpe/veri log/bsrc/dcach eharder_ V . dump 
/u/tbr/euterpe/veri log/bsrc/dcachehar der_0 . dump 
/n/nosfaeratu/s2/euterpe/verilog/bsrc/dcache_func_].dump 

Lisa R. 

I looked at dcacheharderV. I got tired and didn't finish this one, but what I 
found is that nb put out a packet of ail x's except for the tag. I suspect that 
nb read an unused entry. There is a ut file in 

/u/woody/chip/euterpe/verilogtosrc/dcacheharder.ut that has markers at the 
problem. 

jay 
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From: billz (Bill Zuravleff) 

Sent: Sunday, January 29, 1 995 1 1 : 1 7 AM 

To: 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; 'mws (Mark Semmelmeyer)'; 'Jay Tomlinson'; 
'Richard Dickson' 

Subject: bsrc BOM 214.4 fab's 
Y'all, 

For me, bsrc BOM 214.4 fab's on tests 
dcacheeasy_V, dcacheharder V, dcacheannoying_V. 
(results in -billz/euterpe/verilog/bsrc). 


Regards, 
billz 
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From: lisar (Lisa Robinson) 

Sent: Sunday, January 29, 1995 12:43 PM 

To: 'billz (Bill Zuravleff)' 

Cc: 'dickson (Richard Dickson)'; 'mws (Mark Semmelmeyer)'; 'tbr (Tim B. Robinson)'; 'Jay Tomlinson' 
Subject: bsrc BOM 214.4 tab's 

Bill Zuravleff wrote (on Sun Jan 29): 
Y'all, 

Forme, bsrc BOM 214.4 fab's on tests 
dcacheeasy_V, dcacheharder_V, dcacheannoying_V. 
(results in ~billz/euterpe/veriIog/ r bsrc). 


Regards, 
billz 

Thats great. I'm having problems with unreproducible simulation 
results again. However I do have the following dumps: 


/u/tbr/euterpe/verilog/bsrc/icacheann oy ing_0 . dump 
/n/nosferatu/s2/euterpe/verilog/bsrc/saaseasy_0.dump 
/n/nosferatu/s2/euterpe/bsrc/dcache_func_l.dump - but probably better 
to pick up 214.4 first. 

Bill are you in a position to do a top level release? 
Lisa R. 
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From: dickson (Richard Dickson) 
Sent: Sunday, January 29, 1 995 4: 1 7 PM 
To: W 
Subject: ???? 

tim, 

does this have to do with the disk flux ??? 

Protocol error, gamorra.microunity.com closed connection 

mv: gards/es-pass3.gplace.lis: Cannot access: No such file or directory 

gmake[2]: *** [gards/es-pass3.gplace,lis] Error 1 

gmake[2]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/es' 
gmakefl]: *** [es-base.netcap] Error 1 

gmake[!]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/es' 
gmake: *** [esgards] Error 1 

dickson 
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Sent: 
To: 


From: 


geert (Geert Rosseel) 

Sunday, January 29, 1995 4:30 PM 

'sysadmin' 


Cc: 'tbr 1 

Subject: Layout machines 

All Compass machines have problems getting to /n/auspex/s23 . This 
is where a large section of our chip databse lives. I guess they all need 
rebooting. : 

euterpe, kephalos, millennium, athena, poseidon, 


Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Frank Paturzo [fgp@gaea] 
Sunday, January 29, 1995 5:12 PM 
'Geert Rosseel' 
'sysadmin@gaea'; 'tbr@gaea' 
Re: Layout machines 


At 2:30 PM 1/29/95, Geert Rosseel wrote: 

> All Compass machines have problems getting to /n/auspex/s23 . This is 
>where a large section of our chip databse lives. I guess they all need 
>rebooting . : 

> 

> euterpe, kephalos, millennium, athena, poseidon, 
> 

> Geert 


Done . 


Frank Paturzo 


f gp@microunity . com 
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From: lisar (Lisa Robinson) 

Sent: Monday, January 30, 1995 12:23 PM 

To: 'tor'; 'tony'; 'dbulfer'; 'paulb' 

Cc: 'mouss' 

Subject: Pandora spec. 

This note is just to make sure you are all in sync with respect to the 
specification(s) being written. 

I have recommended to Paul that the document discussed in your Friday 
(lpm) meeting is re-named to be Pandora (Media) Workstation 
Engineering Specification. 

AAAAAAAAAAA 

Like the Hestia Specification this will contain a description of what 
Engineering is building. It will tie together data that has 
cross-functional implications. Eg, configuration, power dissipation, 
devices supported etc. It will be available on-line in the Pandora 
documentation tree. It will NOT contain target customer, target 
cost, reliability goals etc. 

The document discussed later that afternoon will be entitiled Pandora 
(Media) Workstation Product Marketing Specification. 

AAAAAAAAAAAAAAAAA 

Also, since I am not sure that many people are aware of the Pandora notes 
and associated documentation I will email their location later today. 

Lisa R. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


mws (Mark Semmelmeyer) 
Monday, January 30, 1995 1:37 PM 
'geert (Geert Rosseel)' 

'dickson (Richard Dickson)'; 'woody (Jay Tomlinson)'; 'tbr (Tim B. Robinson)' 
Re: Euterpe timing errors 


Geert wrote (on 17jan95) : 

> Here are the timing violations of the latest top-level run. 

> This is the one that has It between at & nb, and the re -arranged 

> datapath, 

> More detailed info is in : 

> /n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards/geert_euterpe- top . stat 
> 

> ****** 

> uu to au 

> ****** 

> 

> Warning! Cycle time exceeded by 29.74ps using cycle time of 926.00 

> for 

Iteration 1 HARD ERROR 3 811 

> Path After Optimization using cycle time of 926.00: 

> uu/UwrapAuLvaSelUXRO/ul (xbhrdf32s 32S) Oport : Q_AND0PF IntDel : 
244.80 net: UUwrapAuLvaSelUXR0_N<l> swg: df delay: 266.04ps (force) RC 
delay: 88.06ps Ids: 7 pcap: 84 . 05f f cap: 469.27ff (ext) m21en: 0.00 
m3len: 3502.00 m4len: 0.00 

> au/u203/u0 (xbor3dh32s 32S) Iport : D2_A0PF Oport: 
q_and0ph IntDel: 138.20 net: au/sfrcl4b swg: dh delay: 9.81ps (force) 

RC delay: 0.44ps Ids: 1 pcap: 21.37ff cap: 49.27ff (ext) m21en: 64.00 
m3len: 87.00 m4len: 0.00 

> au/u208/u0/u0 (xbmuxen2dhl6s 16S) Iport: D0_AD0PH Oport; 
q_ad0ph IntDel: 72.60 net: au/u2 08/u0/m swg: dh delay: 8.09ps 
(force) RC delay: 0 . 07ps Ids: 1 pcap: 8.85ff cap: 20.55ff (ext) 
m21en: 30.00 m31en: 27.00 m4len: 0.00 

> au/u208/u0/ul (xbffdf4s 4S) Iport: D0_ADMPH IntDel: 


In an earlier mail on the same path, I wrote: 

> I think this was once a 2 tick path because uu sent it out of an hr. 

> UU could decode the signal earlier so that the driving flop could be 

> local. However, because a muxenff macro was used, it really is a "3 

> gate" path and is going to always remain a little stressed. 

Of course, if the path is only 3 Ops over with uu-au transmission, maybe the 3 gate path 
will work with a local flop in AU. Then would we tolerate a 3 gate path? Should we make 
this change? 


216.20 


> 


Time through Path: 955.74 
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From: billz (Bill Zuravleff) 

Sent: Monday, January 30, 1995 2:50 PM 

To: 'geert' 

Subject: Re: nb status 


The data in the snapshot may be different from /u/chip. You probably should point to the 
snapshot proteus to build the sub-blocks. 

I don't understand. 

You mean link my -/euterpe/proteus to something_other_than_u/chip/proteus 
? 

??? Surely, I don't want to be running down problems in an out-of-date portion of the data 
base . 

billz 
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Subject: 


From: 
Sent: 
To: 
Cc: 


fwo (Fred Obermeier) 

Monday, January 30, 1995 3:50 PM 

'hardheads' 

'two' 

Csyn Euterpe BOM 214 results. 


Hi, 


Csyn results of tbr_euterpe-passl . spivs generated from bsrc BOM 214.0 indicates that there 
is an inconsistent phase connection. Excerpts are from 
/u/f wo/chip. bsrc/euterpe/verilog/bsrc/SAVE .214/* . csyn 


ClockPhase (old style) checks: 

error{1540), inconsistent phase in ckt top: 

xpllO . ckf root Oalph 
pleus . clockroot_adlph 

xpllO . ckf rootO_blph 
pleus . clockroot_andlph 


error(1540), inconsistent phase in ckt top: 

xplll . ckf root l_alph 
pleuh . clockroot_adlph 

xplll . ckf root l_blph 
pleuh . clockroot_andlph 


Please contact me if you have any questions on how to fix this. 

The build of bsrc BOM 215 fail, so now I'm building 216 instead. 
Fred. 
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From: 


tbr 


Sent: 
To: 

Subject: 


Monday, January 30, 1995 8:55 PM 
Vo' 

Mnemo top level 


Follow Up Flag: Follow up 
Flag Status: Red 


I am debugging a version with the temp sensor, pll, knob city etc. 
Why is it we have vdde in the top level (using euterpe as an example), 
but not vsse? 


Tim 
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From: wayne (Wayne Freitas) 

Sent: Monday, January 30, 1995 8:59 PM 

To: 'yves'; 'arya'; 'rmm'; 'dane'; 'graham'; 'tbr'; 'bill' 

Subject: Voltage plane tests 

Heres the initial data, I'll send this out to a larger group after I finishing adding 
some additional notes. Note, new test are on the bottom. 

Wayne 


TEST: 


Continuation of basic power test. I'm going do a simple 
check of the PWB under static load conditions to see the voltage drop 
and temperature gradient across the board. Test conditions are as 
follows, Using a HP665 1 A linear power supply connected to the 3.3 
volt input (where the DC-DC Module mounts) I will provide a constant 
voltage of 3.300VDC. Then using the HP6060B electronic load I will vary 
the load in Samp increments upto 45amps. At each increment I will 
measure the temperature and voltage drop at specified points. This 
test will have the 6060B configured with transients "off', and have 
the external sense line "on" connected at the power input source. 

Room temp = -23 Degree using a Fluke87 with 80T-IR probe. 
Load is currently only connected at Euterpe, as follows: 
using 3 sides with -35 VCC via's 8ea. 28awg wire are brought up 
-.1 " and then connected to a 12awg wire that run the perimeter 
of the Euterpe footprint. This is then connected by < 6" of 12awg 
wire to the load. 

All voltage measurements are done using a Fluke87. Three points are 
measured at Calliope, Euterpe, and ~ 1 " away form the Power Input. 


Volts Amps Points 

Eu Ca Po 

3.30V 1A 0.001,3.299,23 0.001,3.300,23 0.000,3.300,23 

3.30V 5A 0.005,3.292,23 0.003,3.300,23 0.000,3.300,23 

3.30V 10A 0.010,3.283,23 0.007,3.298,23 0.002,3.299,23 

3.30V 15A 0.015,3.274,26 0.011,3.297,24 0.002,3.298,26 

3.30V 20A 0.020,3.265,27 0.014,3.296,25 0.003,3.297,27 

3.30V 25A 0.025,3.256,27 0.018,3.295,25 0.004,3.295,29 

3.30V 30A 0.031,3.248,29 0.022,3.294,25 0.006,3.294,31 

3.30V 35A 0.036,3.239,31 0.025,3.292,25 0.006,2.293,33 
3.30V 40A 
3.30V 45A 


SUMMARY: 

Seems the temperature gradient problem I had before was due to the 
shorted -sense trace dissipating into the poly amide. Voltage drop number 
seem alright considering all current is going through the Euterpe pins 
and only -60% of VCC pins are connected. Will follow through after I 
add the same modification to Calliope pins. Tests will also expand to 
include additional test measurement points by the RF section. Numbers 
to be passed on to board layout engineers for verification. 
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2.1.2 voltages ============== 

Who : wayne 

Date: Fri Jan 27 14:16:55 PST 1995 


TESTS: 


Continuation of power distribution tests. The DC-DC module is 
now mounted on with the sense wire fix and a fan running to keep 
it cool. Currently I have the sense resistors loaded for Calliope 
I also found out that I needed to hardwire the VCC to the 
+sense because the lead actually connects to the VCC Output 
from Calliope. 

Measurements will now be performed with a HP3457A Multimeter 
using a 4 wire measurement. 1st I'll duplicate my previous 
set-up and measurements to establish a correlation. I'm not going 
to do any temperature measurements because of the fan, and the 
measurement device doesn't seem to like the DC-DC Modules heat 
sink. 


With the main board power off I did a simple sanity check, 
I've included them as "OA". 


Amps 

OA 
1A 

5A 

10A 

15A 

20A 

25A 

30A 

35A 


Points 


Eu 

O.OOmV 
1.18mV, 
4.96mV, 
9.73mV, 
1 4.52m V, 
19.33mV, 
24.13mV, 
2 8. 96m V, 
33.82mV, 


3.810 
3.336 
3.333 
3.341 
3.344 
3.346 
3.349 
3.353 


Ca 
O.OOmV 
0.90mV, 3.810 
3.27m V, 3.343 
6.32m V, 3.353 
9.37m V, 3.363 
12.42mV, 3.373 
15.48mV, 3.383 
1 8. 54m V, 3.393 
21.65mV,3.403 


Po 

O.OOmV 
0.000,3.813 
0.000,3.344 
0.000, 3.355 
0.000, 3.367 
0.000, 3.378 
0.000, 3.389 
0.000, 3.400 
0.000,3.411 


1 talked to Noel and got the following values for the chips. 
Nominal values given Calliope 17A @3.3V 
Euterpe 28A @3.3V 

Same set-up as before except Calliope now has a power ring 
and I will be using a second load for simulating various 
loading conditions. Measurements are given ~ l-2minutes 
to stabilize. 


Eu Ca 

20A 10A 

25A 10A 

30A 10A 

35 A 10A 

20A 15A 

25 A 15A 

30 A 15A 

35A 15A 

20A 20A 

25A 20A 

30A 20A 

35A 20A 

20A 25A 


26.15mV, 
30.19mV, 
35.91mV, 
40.85mV, 
29.15mV, 
34.04mV, 
38.96mV, 
44.02mV, 
32.33mV, 
37.25mV, 
42.24mV, 
47.42mV, 
35.65mV, 


Eu 
3.351 
3.361 
3.367 
3.364 
3.360 
3.367 
3.365 
3.360 
3.369 
3.367 
3.364 
3.362 
3.369 


23. 00m V, 
25.77mV, 
28.92mV, 
32.27mV, 
27.66mV, 
31.03mV, 
34.10mV J 
37.61mV, 
32.89mV, 
36.15mV, 
39.75mV, 
42.94mV, 
38.16mV, 


Ca 

3.353 
3.379 
3.373 
3.395 
3.365 
3.377 
3.383 
3.390 
3.361 
3.367 
3.388 
3.378 
3.353 


O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 
O.OmV, 


Po 
3.393 
3.405 
3.414 
3.420 
3.999 
3.411 
3.415 
3.433 
3.407 
3.412 
3.428 
3.435 
3.407 
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25A 25A 40.61mV, 3.364 
30A 25A 45.72mV, 3.363 
35A 25A 50.93mV, 3.366 


4 1 .45m V, 3 .363 O.OmV, 3 .422 
44.90m V, 3.373 O.OmV, 3.424 
48.48m V, 3.383 O.OmV, 3.434 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday, January 30, 1995 9:41 PM 

'mws (Mark Semmelmeyer)' 

'dickson (Richard Dickson)'; 'geert (Geert Rosseel)'; 'woody (Jay Tomlinson)' 
Re: Euterpe timing errors 


Mark Semmelmeyer wrote (on Mori Jan 3 0) : 

Of course, if the path is only 3 Ops over with uu-au transmission, 
maybe the 3 gate path will work with a local flop in AU. Then would 
we tolerate a 3 gate path? Should we make this change? 

If you think it will fix it, I suggest making the change. At the end of the day, if it 
makes timing, I don't see it matters if it's a 3 gate path. 


Tim 
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From: 


tbr 


To: 


Subject: 


Sent: 


Monday, January 30, 1995 11:29 PM 
*vo'; warnler' 
Mnemo clockbias 


Follow Up Flag: Follow up 
Flag Status: Red 


It looks to me like the Mnemo clockbias structure has the 
euterpe IO PLL to clock mast end distribution stuff in it. 
I assume this has come over by starting from the euterpe. 
What's needed to eliminate it? 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Monday, January 30, 1995 11:39 PM 
'wampler (Kurt Wampler)' 

Re: forwarded message from Mail Delivery Subsystem 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Mon Jan 30): 
tbr writes: 


>It looks to me like the Mnemo clockbias structure has the 
>euterpe IO PLL to clock mast end distribution stuff in it. 
>I assume this has come over by starting from the euterpe. 
>What*s needed to eliminate it? 

In /u/chip/mnemo/cIockbias/Makefile, we find the following code: 


# Special spar designations: [nsu]%d 

# BSPAR: the half-spar which will carry the main buffer chain 

# CSPAR: the half-spar which will carry the clock domain control block 

# RSPAR: the half-spar which will carry the auxiliary repeater chain 

# 

BSPAR = sO 
RSPAR = si 
CSPAR = s2 


To eliminate the repeater chain, change the "RSPAR" line to: 
RSPAR = u0 

The code V indicates that there is no repeater chain. 

Then, delete "clockbias.edif ' and re-run the clockbias make. 

-Kurt 

Great! Thanks 
Tim 
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From: wampler (Kurt Wampler) 

Sent: Monday, January 30, 1995 11:39 PM 

To: W 

Subject: Re: forwarded message from Mail Delivery Subsystem 

tbr writes: 


>It looks to me like the Mnemo clockbias structure has the 
>euterpe 10 PLL to clock mast end distribution stuff in it. 
>I assume this has come over by starting from the euterpe. 
> What's needed to eliminate it? 

In /u/chip/mnemo/clockbias/Makeflle, we find the following code: 


# Special spar designations: [nsu]%d 

# BSPAR: the half-spar which will carry the main buffer chain 

# CSPAR: the half-spar which will carry the clock domain control block 

# RSPAR: the half-spar which will carry the auxiliary repeater chain 

# . 

BSPAR = sO 
RSPAR = si 
CSPAR =s2 


To eliminate the repeater chain, change the "RSPAR" line to: 
RSPAR = uO 

The code "u" indicates that there is no repeater chain. 
Then, delete "clockbias.edif ' and re-run the clockbias make. 
-Kurt 
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From: vanthof (vant) 

Sent: Tuesday, January 31 , 1 995 8:05 AM 

To: 'bpw (B. P. Wong)'; 'mikew (Mike Wageman)'; 'orlando (Orlando Hernando)*; 'geert (Geert 

Rosseel)' 

Cc: 'vanthof (Dave Van't Hof)'; 'solo (John Campbell)' 

Subject: cache lower drc's 


The lower drc's for the cache finished and the results are in: 

/ u /vanthof / compass /mobi /euterpe/ cache .err 

If anyone is interested in looking at these, have fun. The output file size is 1/10 of 
the previous run. . . 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 
Sent: Tuesday, January 31 , 1 995 9:28 AM 
To: 'billz'; 'dickson'; 'jefmY; 'rows'; W; 'woody' 
Subject: Test status 


BOM 216 running on IKOS 

BOM 214 ish + uu running on the zycads 

uncruptO Running now 

icacheannoying_0 2 1 6 - Dump in /u/tbr/euterpe/verilog/bsrc 

} 


dcache_fiinc_l 
dcache_sz_4k_l 
dcache_sz_8k_l 
dcache sz I 6k 1 


} Trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/30 195. 18441 


scaseasy 

exlocktestO 

oc-interrupt_U 

brmisstest_0 

bdownharder_0 

bgateJJ 

hlb_l 

ex 11 test 


216 hung 
216 went to X 

216 went to X } 
2 1 6 went to bad very early in the test } 

216 - went to bad 
216 - went to bad 


206 Test fix in 
Running in verilog now. 

214 Ran in verilog on 2 1 6 but test seemed to be working see wrap.log in /u/tbr/euterpe/verilog/bsrc 


dramloadconflglO } 

dramstoreuniqueconfiglO } 2 1 5 went to X Lisar to look at 
dramharderconfig 1 0 } 

cerbarbeasy_0 I need to talk to Rich and Jeffm about this one 
eventdaemontest_0 2 1 4 
Have not yet been run: 


saastest_0 

scastest_0 

uncruptharder_0 

brpcruptO 

brpcrupt2_0 

brpcrupt3_0 

watchtestO 

dcachestressl 
dcache_except_l 


runnmg now 
running now 
running now 
running now 


nb 1 
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nb_slow_l 

nb_hermes_l 

nb_combo_l 

oc-synch_U 
oc_align_at 
align_ld_l 
align_st_l 

doubleextestO 

cerberrtest_0 

cerbstarttest_0 

doublemctestj) 

iorupttest_0 

ruptpintest_0 

brimmlongtest_0 

interrupt_l 

meml 

each el 

exception_l 

bgatej 

barrell 

synchl 

gtlb_miss_l 

dcache__perf_ld 1 t_l 
dcache_perf_st 1 1_ 1 
dcache_perf_ldst 1 1_ 1 
dcache_perf ldst5t_l 

addrmapdram 

fva_conflict_l 

hermesconflictl 

dcache_conflict_l 

atomic_conflict_l 

reg_conflict_l 

interruptU 

exception_U 

bgate_U 

mem U 

tlb_U 

synchU 

barrel_U 

cacheU 

gtlb_miss_U 

Cannot yet be run: 


instr_U 
instrl 
tlb_l 
insn_l 

Newly available tests 


xlu_rotate_l_l 
xlu_rotate_2_J 
xlu_expand_l_l 
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xlu compress 1 

1 

xlu extract 1 1 


xhf field rr 


xlu field 2 1 


xlu field 3 1 


xlu field 4 1 


xlu_field_5_l 


xlu_copyswap_l_ 

1 

xlu_copyswap_2_ 

1 

xlu_copy swap_3_ 1 

xl u_copy s wap_4_ 

1 

xlu_shufflemux_l 

1 

xlu__select_l_l 


Not yet implemented: 

syncharder 

notimp 

brcolltest_0; 

notimp 

brcrosstest_0; 

notimp 

exfixtest_0; 

notimp 

expriotest_0; 

notimp 

uuseqtest; 

notimp 

canceltest; 

notimp 

hermtotest; 

notimp 

cerbtotest; 

notimp 

hermerrtest; 

notimp 

cerberrtest; 

notimp 

eventregtest; 

notimp 

exintbashtest; 

notimp 

addressjriap; 

notimp 

instcache; 

notimp 

cerb_regi sters_0; 

notimp 

cerberror_0; 

notimp 

testerinit_0; 

notimp 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, January 31, 1995 11:31 AM 

To: 'lisar (Lisa Robinson)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr 4 

Subject: Test status 

Lisa Robinson wrote (on Tue Jan 3 1): 

icacheannoying_0 216- Dump in /u/tbr/euterpe/verilog/bsrc 
I will look at this one. 

Jay 
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From: tbr 

Sent: Tuesday, January 31, 1995 11:40 AM 

To: 'dickson'; 'mws'; 'billz'; 'lisar 1 ; 'woody jeffm' 

Subject: Euterpe status 

Follow Up Flag: Follow up 
Flag Status: Red 

10am let's take stock of current verification status. 
Tim 
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From: tbr 

Sent: Tuesday, January 31 , 1 995 1 1 :42 AM 

To: 'hopper'; 'geert'; 'lisar 1 

Subject: Euterpe tapeout date 

Follow Up Flag: Follow up 
Flag Status: Red 


Can we meet at 1 1 please to formalize the timeline for Euterpe 
tapeout. Mouss want's to see this at theschedule meeting tomorrow. 

Tim 
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From: tbr (Tim B. Robinson) 

Sent: Tuesday, January 31, 1995 11 :42 AM 

To: 'hopper'; 'geert'; 'lisar' 

Subject: Euterpe tapeout date 


Can we meet at 11 please to formalize the timeline for Euterpe tapeout. Mouss want's to 
see this at theschedule meeting tomorrow. 

Tim 
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From: billz (Bill Zuravleff) 

Sent: Tuesday, January 31, 1995 11:55 AM 

To: 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; 'jeffm (Jeff Marr)'; 'Mark Semmelmeyer'; 'Richard 
Dickson'; 'Jay Tomlinson' 

Subject: dcachenoalioc 

Y'all, 

test dcachenoalioc goes to X's (examined in ~tbr/euterpe/veri1og/bsrc). 
Because LTcdMissVldCcR.12 goes high while LTcdMissR12 is X. 
Because TDtagR7R8 is X (throughout the test). 

At this point I'll have to parse the test a bit better, but ... 

Surely a load or store noalloc working depends on the tag being 
properly initialized (it's got to know whether it was a hit or not). 
Does dcachenoalioc initialize the tags? 

The entire tag has unknown values at the beginning and end of the 
test. 

Regards, 
billz 
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From: vo (Tom Vo) 

Sent: Tuesday, January 31, 1995 12:05 PM 
To: Tim B. Robinson' 
Cc: 'woody (Jay Tomlinson)' 
Subject: Re: Mnemo top level 

Tim B. Robinson wrote .... 

> 

> 

>I am debugging a version with the temp sensor, pll, knob city etc. 
>Why is it we have vdde in the top level (using euterpe as an example), 
>but not vsse? 

> 

>Tim 

> 

Don't know . Woody put that in a while back for some board level 
stuff . We don't have vdde/vsse for calliope . 

tvo 
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To: 


From: 


Sent: 


stick (Bruce Bateman) 

Tuesday, January 31, 1995 12:06 PM 

'geert'; 'paulp'; 'torn 1 ; Vanthof ; 'hopper' 


Cc: 'tbr'; 'bpW 

Subject: holes in wide metal on the cache 

I understand now that we are going to fill in the holes on wide 
metal busses in the euterpe cache blocks and expect to 're-perforate" 
them to new rules which are yet to be determined. I just wanted 
to advise y'all that the wide busses in the read-port decode were 
very close to the electro-migration limit as originally designed 
and thus electromigration must be considered in any new proposal 
for bus perforation. If we reduce the effective width of these 
busses to any significant degree with the new rules, we could end 
up have a reliability problem. 


BB 


Exhibit CIO 


Page 349 of 356 


From: woody (Jay Tomlinson) 

Sent: Tuesday, January 31, 1995 12:49 PM 

To: 'vo (Tom Vo)' 

Cc: Tim B. Robinson' 

Subject: Re: Mnemo top level 

Tom Vo wrote (on Tue Jan 31): 
Tim B. Robinson wrote .... 

> 
> 

>I am debugging a version with the temp sensor, pll, knob city etc. 
>Why is it we have vdde in the top level (using euterpe as an example), 
>but not vsse? 

> 

>Tim 


Don't know . Woody put that in a while back for some board level 
stuff . We don't have vdde/vsse for calliope . 

tvo 

We have vdde so that we can connect it at the top level, vsse never makes it 
through the tab frame. In the PCAD environment we added pin 3 13 to connect to 
gnd. Calliope doesn't have this stuff. It has to be added manually in the 
morpheus library. Euterpe can be converted without manual intervention. 

Jay 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, January 31, 1995 1:02 PM 

To: 'jeffm'; 'woody' 

Cc: 'tbr' 

Subject: eventdaemontest 


Just confirming that all 8 hermes devices are configured with 
event_register_active on. 


hermesOO NEVENTREGISTERACTIVE 1 

hermesOl NEVENTREGISTERACTIVE 1 

hermes02 NE VENTREGIS TERACTI VE 1 

hermes03 NEVENT REGISTER ACTIVE 1 

hermeslO NEVENT REGISTER ACTIVE 1 

hermes 11 NE VENTREG ISTER_AC TI VE 1 

hermes 12 NEVENT_REGISTER_ACTIVE 1 

hermes 13 NEVENT REGISTER ACTIVE 1 


HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 

HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 
HERMES PROTEUSZLIB 


So the trace in 

/n/aphrodite/s3/euterpe/veri!og/bsrc2/res/3 1 1 95 .27853/resuIts/eventdaemontest.dpo 
(note that this is not an exported file system). 
Lisa R. 
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From: tbr 

Sent: Tuesday, January 31 , 1 995 2:49 PM 

To: Vo (Tom Vo)' 

Subject: Re: cli 

Follow Up Flag: Follow up 
Flag Status: Red 


Tom Vo wrote (on Tue Jan 31): 

Tim B. Robinson wrote .... 

> 

> 

>ls it right that we are using the same vrr for both the vrr and vtt 
>inputs to cli? 

> 

>Tim 

> 

Does not sound right . The vtt inputs to cli should be the same as the ones 
going to iobyte . 

Please take a look at euterpe. That's where I copied it from. 

Tim 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, January 31 , 1 995 3: 1 7 PM 

To: 'billz'; 'jeffm' 

Cc: 'tbr' 

Subject: dcachenoalloc dump 

Is in -tbr/euterpe/verilog/bsrc. 
Lisa R. 
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From: vanthof (vant) 

Sent: Tuesday, January 31, 1995 3:52 PM 

To: 'hardheads' 

Cc: Vanthof (Dave Vant Hof)' 

Subject: fullchip drc/lvs runs starting 


Hi, 

Tin about to start up some fullchip drc/lvs runs on euterpe. Present 
plans require 6 'cpus' (3 dual processor spare 10's) and one more machine for 
normal drc/lvs runs. These machines are cyclops, tomato, mothra, and medusa. 
Please refrain from using these machines while the fullchip runs are going. 
The verification runs last a minimum of 3-4 days each and many of these will 
be run over the next month until tapeout 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std disclaim. h> 
Don't blame me, I didn't vote for him! 
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From: 
Sent: 
To: 

Subject: 


vicki [vicki@charybdis] 
Tuesday, January 31, 1995 7:35 PM 
'Geert Rosseel' 
Call Lieve at home. 


Hi, 


I'm about to start up some fullchip drc/lvs runs on euterpe. Present plans require 6 
'cpus' {3 dual processor spare 10' s) and one more machine for normal drc/lvs runs. These 
machines are cyclops, tomato, mothra, and medusa. 

Please refrain from using these machines while the fullchip runs are going. 

The verification runs last a minimum of 3-4 days each and many of these will be run over 

the next month until tapeout. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ^include <std_disclaim . h> Don't blame 
me , I didn • t vote for him ! 


Thanks , 
Dave 
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From: vo (Tom Vo) 

Sent: Tuesday, January 31 , 1 995 1 1 :49 PM 
To: Tim B. Robinson' 
Subject: Re: cli 

Tim B. Robinson wrote .... 

> 
> 

>Tom Vo wrote (on Tue Jan 31): 

> 

> Tim B. Robinson wrote .... 

> > 

> > 

> >Is it right that we are using the same vrr for both the vrr and vtt 

> >inputs to cli? 

> > 

> >Tim 

> > 
> 

> Does not sound right . The vtt inputs to cli should be the same as the ones 

> going to iobyte . 

> 

>Please take a look at euterpe. That's where I copied it from. 

> 

>Tim 

> 
> 

The one in euterpe. V needs fixing too . 

A similar problem exists in calliope with the cell clio 

where it propagated to euterpe.V then mnemo.V . 

This hook up error prevents us from trying all values of 
termination resistances unless the knob dedicated to clio 
is set to 1 1 1 . The values permitted is the bitwise AND 
of clio knob setting and termination value setting from 
cerberus . 

I've issued a gnat report on this problem for calliope and 
checked in a change for euterpe . 

tvo 
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